[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <811c90f8-7ee3-fa86-281d-49c6e3c70400@ludocode.com>
Date: Sat, 16 Apr 2022 19:59:23 -0400
From: Nicholas Fraser <nick@...ocode.com>
To: musl@...ts.openwall.com
Subject: Re: Detect qsort_r() support with preprocessor
On 2022-04-16 14:42, Quentin Rameau wrote:
> > Like I said, I don't control the compiler flags with which my users will
> > compile my library.
>
> You actually do, or at least should.
> It's ok to have requirements about a software to work, usually
> dependencies, but requiring a standard (as in POSIX) environment is
> regular and totally legitimate.
>
> If your users decide to break your application expectations, then they
> must have good reasons for it and should deal with it.
But my software doesn't actually have such a requirement in reality. Why should
I need to add a requirement about language standards just because you won't
give us any in-language way to detect qsort_r()? My users should not need to
worry about low-level things like whether they've defined _GNU_SOURCE or
_POSIX_C_SOURCE just to use my code.
Besides, why do you equate having a requirement with having to configure it
manually? Why can't it just detect automatically with the preprocessor whether
its requirements are met? Again, no manual configuration is necessary on any
other platform.
Note that my library doesn't even have qsort_r() as a requirement. I have a
fallback but I would prefer to use what's available on the platform. This is
why it's especially important for the configuration to be automatic: if the
configuration is manual and they don't configure it properly it will still work
but with suboptimal code. This is just as error-prone as any of your
hypothetical failure cases with __MUSL__.
Header-only configure-free libraries are specifically designed not to impose
compiler flags or other requirements on their users. That is in fact the whole
point, to not force users to build it in a special way and instead let them
build it the same way as the rest of their code simply by #including it. For my
libraries in particular, I go to great lengths to test that they compile
cleanly under a wide variety of compiler flags on many different platforms so
that users don't need to think about any of this stuff in order to use the
code.
> > If I can reliably detect with the preprocessor whether the
> > platform has a qsort_r() function
>
> That is the point, you cannot in the way you're going at it (until
> POSIX-next is released).
You're confusing theory with practice. Of course I won't be able detect it on
some theoretically perfect POSIX libc, but I don't care, because no such libc
exists. I care about what works in practice. In practice, I can quite reliably
detect qsort_r() with the preprocessor everywhere but musl.
musl is certainly not that theoretically perfect POSIX libc by the way. For one
thing, you have qsort_r(), and it's under _GNU_SOURCE. Surely you've merged it
not for theoretical reasons, but because you actually want people to use it?
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.
