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, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11971 invoked from network); 19 Apr 2022 03:39:08 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 19 Apr 2022 03:39:08 -0000 Received: (qmail 5248 invoked by uid 550); 19 Apr 2022 03:39:04 -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 5213 invoked from network); 19 Apr 2022 03:39:04 -0000 Message-ID: <823acf0f-461d-d599-feb7-e0e21cfeb51d@ludocode.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ludocode.com; s=key1; t=1650339532; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ytUy4bi8HsdSaBqhHI35+VhB4+S485CE3foeF/22hxs=; b=Axu++OrfThpnTkii6IXYxa+5nad1FaDCqan7qufZ5FYNSRm+d82Lg9jyI9EEZnXAcPNbT/ xtcIqQKajTQqxkFrVR+5ovoQmKPB0Mq6nuE8h/hPbyT93jNqcWP7G+2qnFcMFxtNcyflfr t4DvrBs/tBvuEF+Iew2C0+STFc5QP8s66Q1hF51azsF6VXPHoy+n8TGATom07A6JtVRJwW YYfztuLEZDCWeMfqv9PciTJhkBQIvec5MTXpCkfRdTJF5bqRrcoxb5tAzt+gd9pYy3ptrh Zl4gT8ZbNFLY3NRREftu7wgaJTv5JYFhyz2+Xt4YD38hxPj/BUbqsfmq3a8Q/g== Date: Mon, 18 Apr 2022 23:38:49 -0400 MIME-Version: 1.0 Content-Language: en-US To: Rich Felker Cc: musl@lists.openwall.com References: <87a84620-df28-7e62-23e4-57e52bd068af@ludocode.com> <20220416120154.GA2553@voyager> <20220416161626.55aadace.quinq@fifth.space> <94a82803-acf0-4fb7-158b-b13cae530f6c@ludocode.com> <20220417020403.GZ7074@brightrain.aerifal.cx> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Nicholas Fraser In-Reply-To: <20220417020403.GZ7074@brightrain.aerifal.cx> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: ludocode.com Subject: Re: [musl] Detect qsort_r() support with preprocessor On 2022-04-16 22:04, Rich Felker wrote: > On Sat, Apr 16, 2022 at 01:50:06PM -0400, Nicholas Fraser wrote: >> [long rant of wrong stuff I did not read] It's very sad that you're not interested in hearing the problem, and that you ignore the growing number of single-file and/or header-only libraries in C. Here's a long list of them:     https://github.com/nothings/single_file_libs None of these libraries come with configure scripts. That is in fact the whole point. They're distributed as just source code. There is no reason why plain C source code can't be decently portable entirely on its own without any need for configure scripts. You are just refusing to help us make it work. Yes, it's great that you're trying to standardize macros for it, but what are we supposed to do in the meantime? You seem more interested in adhering to standards than in making working software. I'm going to try to explain my use case in more detail to hopefully give you some perspective on how this works everywhere else and why it doesn't work on musl. If you truly don't care then feel free to ignore this email, but know that you're ignoring a very real use case for a lot of people beyond me and my little library. Just to recap: I'm writing a header-only library. My intention is for users to just put the headers on their include path and use it, no configuration needed. I'd like to use any variation of qsort_r()/qsort_s() that's available on the platform. GNU/musl/POSIX-next qsort_r() and C11 Annex K qsort_s() are virtually the same; Free/Net/DragonFlyBSD and Apple qsort_r() are the same; and Windows qsort_s() is the outlier. There are only three possible prototypes so it's trivial for my code to permute the arguments to match what's available. All I need to do is detect which one the platform has. I won't say "I can detect", because then you'll say "No you can't" even though it works fine, and we'll just go in circles telling each other we're wrong. Instead I'll say "I am detecting". I am detecting glibc and uClibc's qsort_r() with `#ifdef __GLIBC__`. I am detecting Windows qsort_s() with `#ifdef WIN32`. I am detecting macOS and iOS qsort_r() with `#ifdef __APPLE__`. I am detecting the BSDs with `#ifdef __FreeBSD__`, `#ifdef __NetBSD__`, etc. I am detecting C11 Annex K qsort_s() with __STDC_LIB_EXT1__ and other platform macros (e.g. __FreeBSD__.) In cases where the headers declare it conditionally, I simply declare it myself so that my users don't need to define _GNU_SOURCE or __STDC_WANT_LIB_EXT1__ or whatever:     static inline     void mylib_qsort_r(...) {         extern void qsort_r(...);         qsort_r(...);     } This actually works in practice. It imposes no requirements or restrictions on how users compile my code. There is zero configuration, zero scripts to run, zero manual steps to make it work on 99.9% of platforms in existence. I don't need it to work on some platform I've never heard of because the odds of someone trying to use my code on such a platform are very low, but if they ever do, the first person who tries can just send me a patch to add support for it. We know this same strategy will work there too because every other platform in existence declares who they are or what features they have with macros. This strategy works everywhere *except musl*. These are the options you've given me to make my header-only library work on musl: a) Add a configure script to my library. Make my users run the configure    script, possibly execute the tests on target when cross-compiling (probably    not necessary for qsort_r() but definitely for other features), and cache or    install the result somewhere along with my library. (Multiply this step by    every library they use times every platform they support.) b) Make all users of my library either write their own configure script to    detect musl qsort_r() and emit a config.h, or make them write this config.h    manually, and have my library include it. (But, I can't `#include    "config.h"` only on musl because you won't tell me you're musl, so this    config.h becomes an added requirement on *all platforms* even though on    every other platform it will be blank.) c) Use my fallback, which is in fact an entire implementation of `qsort_r()`,    intended only for platforms that don't have one. This is of course the most    attractive option because it's the only one that doesn't add a configuration    burden on my users. Remind me, why did you bother implementing qsort_r()    again? Because the best option you've left me with is the one where I ignore    it. Is this really what you want the future of C programming to be like? You want every little piece of source code to have a configure script attached to it to probe the platform, or have a bunch of manual configuration steps just to figure out what the platform already knows but won't tell us? Are all of musl's features secrets we have to tease out with these out-of-language hacks? Nick