|
Message-ID: <20220419065954.GA1933@voyager> Date: Tue, 19 Apr 2022 08:59:54 +0200 From: Markus Wichmann <nullplan@....net> To: musl@...ts.openwall.com Cc: Nicholas Fraser <nick@...ocode.com> Subject: Re: 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 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 > 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 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. > 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 users 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 wrong. > 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 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__.) > 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_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. 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 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. > 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()`, > 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 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() > again? Because the best option you've left me with is the one where I ignore > 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 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? > 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
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.