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