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.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,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 3398 invoked from network); 19 Apr 2022 07:00:13 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 19 Apr 2022 07:00:13 -0000 Received: (qmail 18104 invoked by uid 550); 19 Apr 2022 07:00:10 -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 18066 invoked from network); 19 Apr 2022 07:00:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1650351597; bh=4VO3ZCS1LA8wYeA61TSNcoEEstA5cZWiK+tMCjVmW74=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:References:In-Reply-To; b=XkNIZg3KZCYwaUKIl8j3FjB96jizTb7Ds3RZWE3Iean4x1wDrIDAkeFI1acwzA8Ka mRku0woDinblTuGUlZqTdyjhPD3BPj/hIt8QRGmqXUXvc0WHWDVukCvzzl7iLneYai NLTOzT7/h1TVeSkH2CxmhBWmyCM4I1PhUlU26GWk= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Tue, 19 Apr 2022 08:59:54 +0200 From: Markus Wichmann To: musl@lists.openwall.com Cc: Nicholas Fraser Message-ID: <20220419065954.GA1933@voyager> 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> <823acf0f-461d-d599-feb7-e0e21cfeb51d@ludocode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <823acf0f-461d-d599-feb7-e0e21cfeb51d@ludocode.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:5/7Sgv+RTwKmUgG76QRl54JPVJcwCiSItp6Tc5wUzGNSFxbynZI KV+tPmV8FKNaroQ3jHxikJQaXUGVhqL5HXmhekrVlgOUrHi92XInGU7C3mLh3j5pKROB+PG AzXSdgyN9JOOWpsg3/pIVpf34sKMKL3COsmgSWcFbJh7Qv5WFqgfeEk3HJFWmbP4qqtfTKt g75Dwmysxnkz0O45FlF9Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:pi0HeBxceqc=:Z1gixnGf8mcmtouZbZxhTK f8z/EGrx16PuyybAuk6IvGN/+yz9hHJVlJa3KoSukAI+qIVP5bAgkwuYjy9fbYoyXjUp05Wqe mFPbyn3o2rD+aKUZycBUq3pahE1sWsGFnGrzVxvq+FuNkhdfqaZ+VRBH9qpYl+0G+v9dVc8CJ 9ETODrIx727g26m7/ZjcQD0V1pLhTzdLBY31P/JyQ5o1MN+FE/WtbLiS+p4mXFngikHHguNuk LPZNlEXteIjU6208zxq3zaDnz4rcgjDnWr0TJDyXo1jdhSN+gjxTV0oAVIrwoIu3wDU61YCIg OuNE5bxltfusRDYkpyW3L/ZarqXZ602flKE178fHk8zQhfq5mDfTM4PgZdRJAvscYY+oR4AkH E20C8yCcxUE8UXt/GFKHehVYPuxQQylN0F03VAvdBMY4FQ93mK84SYPJQdVApJkvP5VT8iLgf Dt4J1OI9jJ+5kPYB0wGiFWOAUubQEY0voAWgn78TK/FCOQdDKXRR2qoTQldXvXl/xb9ruYu2O UrbnwWL3B9zXDHkcHtO8yXHf2eFbf6e8/dqFSRBiYKv2H1M/V73k44cDswE5s7nzyc77FIPsa XKanh4czr6N5iGd1v6lgB0HTRK1q6Mu3hhmmP5GVZNyZa2z/zz3i/8+fw618tdTO/8p6gX1sp bz6Av2zj/vUYQHYZvI6tUI/3JomiqGABC9KNB/vnxFIkvZGSHx3E7mtTD3LKvKV57SC64fiAn ARRdBMI9GpV6GJSGL03s7+2XAnfYJGJEV61pTyv6KPwbakJo6i9C+lAb5fQEWL6QjmQsX7jzb UP1To8wS1GB3I5Jil7Zu1ST+uI4Z0Hpn4opdprZ5GSXd3omLt0g132ltJpL/oloACRLAwkDzC cRVML18T1d0Wve8Gwydu3DdDh36Boib2YPduh3OgGU1nDk6JeepgbepkZjWJBBQYngvv4bdvg OmDSU9CXOmNGv32jj8GraU1n+C9J/bqoIIL/i4aipbHrlqJOCDp2npk/UHDK+/K8VPsc4zxnm QJzw33Te8DGbYgiWQAwyxhlaQ8tYni2D6KbHrpzWGUtofZJ7DXIEcpnjXrTWE2eAVgfY0KrTr VyYn3lX6Db4PgQ= Subject: Re: [musl] Detect qsort_r() support with preprocessor This will likely be pointless, but I'll try once more. On Mon, Apr 18, 2022 at 11:38:49PM -0400, Nicholas Fraser wrote: > It's very sad that you're not interested in hearing the problem, and tha= t you > ignore the growing number of single-file and/or header-only libraries in= C. > Here's a long list of them: > > =A0=A0=A0 https://github.com/nothings/single_file_libs > No, YOU are not interested in hearing the reasons for why what you want is bad and leads to technical debt. There is no reason why single file libraries should not have a config section at the top or something. The only alternative left to you is to use standards that are definitely supported. Since Windows/MSVC is on the list of platforms you wish to support, that means C89. And ONLY C89. Good luck with that. > 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 p= lain C > source code can't be decently portable entirely on its own without any n= eed > for configure scripts. You are just refusing to help us make it work. Ye= s, it's > great that you're trying to standardize macros for it, but what are we s= upposed > to do in the meantime? You seem more interested in adhering to standards= than > in making working software. > That last one has been floated before and just does not fly. You have been pointed in the direction of something to make it work reliably everywhere and refuse to use that solution because apparently you think running a script or writing a 0 or 1 into a single line of configuration is undue burden on programmers who already cannot be arsed to do their job. But making Rich maintain a growing list of macros somehow is not. See, this is what I don't get: Your target audience is programmers, not end users. Can they not be expected to fill in a configuration once? They will already have to expend some effort integrating your library into their programs, anyway, so it hardly changes things. Indeed there is no reason for plain C being unportable. But the only way to really make it portable is to refuse to use any feature beyond the lowest common denominator, which is usually going to be C89. So, no qsort_r() for you. The alternative is to maintain a growing list of assumptions about implementations, each of which may turn around next release without warning. Or, you know, your source code can grow out of date. > Just to recap: I'm writing a header-only library. My intention is for us= ers to > just put the headers on their include path and use it, no configuration = needed. Then maybe that's a bad intention. The only way to do that with the list of platforms you added later is to not go beyond C89. > > 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 wro= ng. > Instead I'll say "I am detecting". > And here the boy who cried "you're not listening" goes on to not listen himself. > I am detecting glibc and uClibc's qsort_r() with `#ifdef __GLIBC__`. I a= m > detecting Windows qsort_s() with `#ifdef WIN32`. I am detecting macOS an= d 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__.) > And you listed all of that stuff with a straight face. didn't you? The only standard macro in all of these is __STDC_LIB_EXT1__, an admittedly rarely used one. What about newlib? newlib is the C implementation underlying much of Cygwin, which last I checked was still pretty popular. At least I use it regularly. And you can get it to define WIN32, but it doesn't have qsort_s(). But it has both versions of qsort_r(). Anyway, what do you want? Imagine if there was a __MUSL__ macro, and had been there last version already. That would mean that the presence of __MUSL__ tells you nothing about whether qsort_r() is supported. So you would need __MUSL_VERSION__ or something. But then Alpine went ahead and backported it to earlier versions. So there are versions of musl 1.2.2 out there with qsort_r() and those without it. So again, the macro you are begging for would not tell you what you want to know. So what you would want is __MUSL_HAS_QSORT_R__, which for a growing list of standard extensions is obviously untennable. If instead you just tested the environment once, you could do it dynamically for all possible C implementations. Or you wait for the next version of POSIX to come out and test the POSIX version macros. That means there will be C libraries with the function you want but not declaring support for them, but then, such is life. > 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_EXT= 1__ or > whatever: > > =A0=A0=A0 static inline > =A0=A0=A0 void mylib_qsort_r(...) { > =A0=A0=A0=A0=A0=A0=A0 extern void qsort_r(...); > =A0=A0=A0=A0=A0=A0=A0 qsort_r(...); > =A0=A0=A0 } > > This actually works in practice. It imposes no requirements or restricti= ons on > how users compile my code. I'm pretty sure it won't work on OS-9. That would be a restriction. > 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 th= ey ever > do, the first person who tries can just send me a patch to add support f= or it. > We know this same strategy will work there too because every other platf= orm in > existence declares who they are or what features they have with macros. > No, they don't declare who they are. They declare who they are emulating. clang defines __GNUC__, uclibc defines __GLIBC__, and why? Because people like you cannot be bothered to run configure tests for the features you want. > c) Use my fallback, which is in fact an entire implementation of `qsort_= r()`, > =A0=A0 intended only for platforms that don't have one. This is of cours= e the most > =A0=A0 attractive option because it's the only one that doesn't add a co= nfiguration > =A0=A0 burden on my users Well, you took the long way around, but arrived at the correct conclusion. Especially in the case of qsort_r(), the only thing that reliably works on all platforms is to implement it yourself in the absence of standard macros. Since you are already doing that, just always using that implementation is less code than whatever harnesses around qsort_r() and qsort_s() you have built. And less code is usually less bad. >. Remind me, why did you bother implementing qsort_r() > =A0=A0 again? Because the best option you've left me with is the one whe= re I ignore > =A0=A0 it. > The best option for you and your highly specific and, frankly, counterintuitive requirements, that have programmers integrate a library but not able to write a config header. > 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 t= o > 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? > What do you mean "future"? At this time you already only have two sort-of reliable ways to detect standard extensions: Either test for them, and due to the fluid nature of many libraries, that means test for the actual interface, not implementation name and version, or else wait for it to be standardized and test for standard macros. The former finds all implementations but requires compile-time configuration, the always works but fails to find some implementations. You have to die some way, so choose. Ciao, Markus