Date: Sat, 16 Apr 2022 19:59:23 -0400 From: Nicholas Fraser <nick@...ocode.com> To: musl@...ts.openwall.com Subject: Re: Detect qsort_r() support with preprocessor On 2022-04-16 14:42, Quentin Rameau wrote: > > Like I said, I don't control the compiler flags with which my users will > > compile my library. > > You actually do, or at least should. > It's ok to have requirements about a software to work, usually > dependencies, but requiring a standard (as in POSIX) environment is > regular and totally legitimate. > > If your users decide to break your application expectations, then they > must have good reasons for it and should deal with it. But my software doesn't actually have such a requirement in reality. Why should I need to add a requirement about language standards just because you won't give us any in-language way to detect qsort_r()? My users should not need to worry about low-level things like whether they've defined _GNU_SOURCE or _POSIX_C_SOURCE just to use my code. Besides, why do you equate having a requirement with having to configure it manually? Why can't it just detect automatically with the preprocessor whether its requirements are met? Again, no manual configuration is necessary on any other platform. Note that my library doesn't even have qsort_r() as a requirement. I have a fallback but I would prefer to use what's available on the platform. This is why it's especially important for the configuration to be automatic: if the configuration is manual and they don't configure it properly it will still work but with suboptimal code. This is just as error-prone as any of your hypothetical failure cases with __MUSL__. Header-only configure-free libraries are specifically designed not to impose compiler flags or other requirements on their users. That is in fact the whole point, to not force users to build it in a special way and instead let them build it the same way as the rest of their code simply by #including it. For my libraries in particular, I go to great lengths to test that they compile cleanly under a wide variety of compiler flags on many different platforms so that users don't need to think about any of this stuff in order to use the code. > > If I can reliably detect with the preprocessor whether the > > platform has a qsort_r() function > > That is the point, you cannot in the way you're going at it (until > POSIX-next is released). You're confusing theory with practice. Of course I won't be able detect it on some theoretically perfect POSIX libc, but I don't care, because no such libc exists. I care about what works in practice. In practice, I can quite reliably detect qsort_r() with the preprocessor everywhere but musl. musl is certainly not that theoretically perfect POSIX libc by the way. For one thing, you have qsort_r(), and it's under _GNU_SOURCE. Surely you've merged it not for theoretical reasons, but because you actually want people to use it? Nick
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.