Date: Sat, 16 Apr 2022 14:01:54 +0200 From: Markus Wichmann <nullplan@....net> To: musl@...ts.openwall.com Subject: Re: Detect qsort_r() support with preprocessor On Sat, Apr 16, 2022 at 04:13:56AM -0400, Nicholas Fraser wrote: > Hello musl devs, > > qsort_r() has been added to musl 1.2.3 and it has been backported to > the previous version of musl in Alpine. How can I detect whether this > function is available using the preprocessor? > > The community wiki advocates "testing" for feature support, which I > guess means compiling a test program like an autotools configure > script. Guess why that is. It is more portable to do that way than to define new non-standard macros. The only macros musl will define are standard ones. > Can we not just test for a macro instead? Have you considered > defining something like `__HAS_QSORT_R` to tell us directly that you > support it? > Unless qsort_r() were part of a new release of POSIX (then you could look at _POSIX_VERSION), or a member of an option group (then you could look at the option group macro), not really. If musl had a bespoke symbol, it would just diverge. Then musl would have its macro, glibc another one, OpenBSD would do a totally different thing again, and in the end you get a leaning tower of hostname (look it up). Plus, adding such a symbol would then basically mean it could never be retracted again. Keep going in that direction for a decade and you get a mess of non-standard symbols to keep track of. > I am writing a cross-platform header-only library. I want my users to > be able to just drop the header files of my library into their > codebase. I really don't want them to have to write their own > configure tests just to tell my library whether musl provides > qsort_r(). It's not supposed to be just for musl. Doing a configure test would correctly detect it in all configurations. Why not have a "config.h", containing all the switches? If set wrong, it just won't compile. If set right, it will compile on platforms you never even heard of. In case of pure computations like qsort_r(), there is also the possibility of the client code remedying a lacking implementation by providing the extension itself, which a version based approach will not detect correctly. > I am able to detect variants of qsort_r() or qsort_s() with > the preprocessor on all other platforms that support such an > extension. I highly doubt glibc for example provides a special symbol for qsort_r() alone, so I am guessing you are querying version numbers. Which of course fails in the face of backporting, and in case of new implementations. Whereas just writing a compile test will not. Ciao, Markus
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.