Date: Sat, 16 Apr 2022 13:50:06 -0400 From: Nicholas Fraser <nick@...ocode.com> To: musl@...ts.openwall.com Subject: Re: Detect qsort_r() support with preprocessor On 2022-04-16 08:01, Markus Wichmann wrote: > 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). All of those other platforms define symbols like __GLIBC__ and __OpenBSD__. They make it easy to detect things with the preprocessor. FreeBSD in particular publishes an exhaustive list of all possible values of __FreeBSD_version and what symbols they change or introduce: https://docs.freebsd.org/en/books/porters-handbook/versions/ It's pointless to use a configure script to detect qsort_r() on any other platform because we can detect it just fine with the preprocessor by using these symbols. Assuming you're referring to "#ifdef Considered Harmful", sorry but a 30 year old paper arguing against the use of #ifdef is not convincing. This paper predates proper function inlining optimizations. It's arguing against littering your code with #ifdefs, whereas now we know we can make zero-overhead wrapper functions to keep the portability separate from the rest of our code. > 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. You wouldn't need a bunch of different symbols if you just defined __MUSL__. Nobody is going to remove qsort_r() from their copy of musl so as long as we know the minimum version in which it's available we'd know it's safe to use it. It doesn't have to be perfect either by the way. As long as it works in most cases we can autodetect those and let users manually configure the rest. > 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. I don't need a config.h for any other platform. I can autodetect things with the preprocessor everywhere except musl. Why should I add one just for musl? You're not considering the growing number of simple header-only libraries for C. Think of the stb libraries for example: https://github.com/nothings/stb These are single-file header-only libraries. Nobody wants to write a configure script for them. Nobody wants to install them into /usr/include. They want to drop the header file into their project and have it "just work". This is possible on every platform except musl. You know configure scripts aren't necessary in any other programming language right? No other language requires the use test compilation to determine the capabilities of the platform. Other programming languages have facilities to tell you what's available within the language itself. So does C, by the way, if you would only just *tell us* with the preprocessor what's available. On 2022-04-16 10:16, Quentin Rameau wrote: > Just as a note, qsort_r() has indeed been added to POSIX-next, so you'd > only need to ask for _POSIX_C_SOURCE with a value of 20XXXX, when it's > actually been released. Well that doesn't help me today. But even if it did, GCC and Clang don't define _POSIX_C_SOURCE automatically. Under glibc it's only defined under -std=gnu*, not -std=c*, and under musl (Alpine) it doesn't appear to be defined either way. Like I said, I don't control the compiler flags with which my users will compile my library. If I can reliably detect with the preprocessor whether the platform has a qsort_r() function, I can use it regardless of whether the headers actually declare it because I can just declare it myself locally in a wrapper function. This works on every platform except musl. Nick Content of type "text/html" skipped
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.