[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220416120154.GA2553@voyager>
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.
