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.