[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220416204213.39e4d0e1.quinq@fifth.space>
Date: Sat, 16 Apr 2022 20:42:13 +0200
From: Quentin Rameau <quinq@...th.space>
To: musl@...ts.openwall.com
Subject: Re: Detect qsort_r() support with preprocessor
Hi Nicholas,
> 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.
Indeed, that isn't something that the compiler should define for the
application, it's for the application to request it.
> Like I said, I don't control the compiler flags with which my users will
> compile my library.
You actually do, or at least should.
It's ok to have requirements about a software to work, usually
dependencies, but requiring a standard (as in POSIX) environment is
regular and totally legitimate.
If your users decide to break your application expectations, then they
must have good reasons for it and should deal with it.
> If I can reliably detect with the preprocessor whether the
> platform has a qsort_r() function
That is the point, you cannot in the way you're going at it (until
POSIX-next is released).
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.
