[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 19 Apr 2022 19:10:23 -0400
From: Nicholas Fraser <nick@...ocode.com>
To: musl@...ts.openwall.com
Subject: Re: Detect qsort_r() support with preprocessor
Thanks for the replies. I'm a bit surprised to hear you agree that, given my
requirements, I should ignore your features and re-implement them myself.
Beyond that it looks like we won't find common ground.
I'll just take the opportunity to clarify a few things:
On 2022-04-19 02:59, Markus Wichmann wrote:
> Since Windows/MSVC is on the list of platforms you wish to
> support, that means C89. And ONLY C89. Good luck with that.
You may be interested to learn that Microsoft has had full C99 support (minus
those features made optional in C11) since VS 2015. This is the oldest version
of the VS tools still supported. More recently, VS 2019 supports nearly all
of C11 (including a conforming preprocessor.)
Even before that, it was easy to make well-written C99 compile as C++ to work
under Microsoft's compiler. Compiling as C++ is a virtual necessity for a
header-only library anyway.
> I'm pretty sure it won't work on OS-9. That would be a restriction.
I think this is the main source of our disagreement. You seem very concerned
that my strategy won't work on platforms I've never heard of, and that if it's
not perfect, it's useless.
I do provide my users the option to manually override whatever I detect in case
it's wrong. I'm just trying to detect as much as I can to make it easier for
them. It's okay if it only works 90% of the time, and the remaining 10%
requires manual configuration. I believe it will be more like >99% though, and
I had hoped musl would want to be part of that >99%.
> 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.
For the record I didn't ask for __MUSL_VERSION__. I asked for __HAS_QSORT_R.
I asked this for exactly this reason, because I've been testing on Alpine and
noticed they backported it. I only brought up __MUSL__ in comparison to what
works for me on other platforms. We all agree that a standard macro like
__HAS_QSORT_R would be a better solution but it will take a decade for this to
get standardized.
In any case, even if a version macro doesn't detect backported features, that's
not a big deal. It's a temporary problem that will solve itself. This is
another case of perfect being the enemy of good.
> So what you would want is __MUSL_HAS_QSORT_R__, which for a growing list
> of standard extensions is obviously untennable.
This isn't obvious at all. I can't imagine what is so untenable about putting
a simple #define next to each extension function you support.
From my perspective, I think what is obvious is that you want to hide the fact
that the implementation is musl, and you are opposed to macros like this simply
because they could be used to reveal that you're musl.
On 2022-04-19 09:32, Rich Felker wrote:
> You cannot #define _GNU_SOURCE or __STDC_WANT_LIB_EXT1__ after any
> standard header has already been included.
Yes, I know that of course (give me a little credit here.) Maybe I was unclear.
I'm not defining _GNU_SOURCE or whatever. I'm declaring the actual libc
function I want to link against within the scope of my wrapper function that
calls it. That's what the snippet of code I showed does. Ultimately I'm
targeting the ABI, not the headers, which is why I make it work regardless of
_GNU_SOURCE and such.
Nick
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.
