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