From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26279 invoked from network); 16 Apr 2022 17:50:23 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 16 Apr 2022 17:50:23 -0000 Received: (qmail 7633 invoked by uid 550); 16 Apr 2022 17:50:20 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 7600 invoked from network); 16 Apr 2022 17:50:19 -0000 Content-Type: multipart/alternative; boundary="------------H1X04A0KnuEdA90ugxUYNnRd" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ludocode.com; s=key1; t=1650131408; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0aBML9U7ESpOJybM0YlNo62X3pVoDMoR4SQt9SkOpxY=; b=Ri8WxPOwvzw5aIwzKhrZVkJYaZb+ReyHjplYtUkj2Y3TwXD3pxxfB6OeyghnmwB5wCWBw1 dinjMyEtwZtUyXjKlrvNLhcO8AVR43Y3UphtuIv5sNKFxQ+PXfxCDXWfNWwhEhVeIw1hKj 2CPq8YT9lGi122JSCwJSDi71TAnTTRBeTeQUKTWU2elzslLZrRvfd5oCXScJVp+crNSZlL LHubosw3hDNUAuBaPMgLiEQPCs38GVDCd+MrY2kxXB/AyNI4yobZBsllzmjLGY3HbPPDgm +/dzzFtInHPmzHFJqk1UzaBipx4M6DWuH+KNuDMN4MfWvgVJgJOXVXmoIV56LA== Message-ID: <94a82803-acf0-4fb7-158b-b13cae530f6c@ludocode.com> Date: Sat, 16 Apr 2022 13:50:06 -0400 MIME-Version: 1.0 Content-Language: en-US To: musl@lists.openwall.com References: <87a84620-df28-7e62-23e4-57e52bd068af@ludocode.com> <20220416120154.GA2553@voyager> <20220416161626.55aadace.quinq@fifth.space> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Nicholas Fraser In-Reply-To: <20220416161626.55aadace.quinq@fifth.space> X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: ludocode.com Subject: Re: [musl] Detect qsort_r() support with preprocessor This is a multi-part message in MIME format. --------------H1X04A0KnuEdA90ugxUYNnRd Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 --------------H1X04A0KnuEdA90ugxUYNnRd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit 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

 --------------H1X04A0KnuEdA90ugxUYNnRd--