Re: [musl] Detect qsort_r() support with preprocessor

[Rich Felker <dalias@libc.org>]

On Sat, Apr 16, 2022 at 01:50:06PM -0400, Nicholas Fraser wrote:
> 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__.

Those do not tell you what you want to know: whether a particular
interface is supported. They tell you a particular implementation name
and version, which then requires you to have massive amounts of
hard-coded knowledge about every platform you support, and to fail to
support any platform you don't know about. This practice belongs back
in the 1980s, not the 2020s.

> 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.

No, it's not. If there were a standard or widely agreed upon macro
that indicated "qsort_r is present and has the signature and semantics
you expect it to have", that would make it possible to detect. But no
such macro exists. I've tried to push forward an effort for defining
an analog of the unistd.h macros POSIX defines, but for
non-standardized but moderately to widely cross-platform extensions,
but nothing has come of that so far. The existing proposal discussion
is in the libc-coord list.

Until that happens, *detecting* in a configure-style manner is the
only way to do this. musl absolutely will not support the practice of
hard-coding assumptions about the implementation.

> [long rant of wrong stuff I did not read]

...

Rich