[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 7 Jul 2023 09:53:02 -0400
From: Rich Felker <dalias@...c.org>
To: Alastair Houghton <ahoughton@...le.com>
Cc: musl@...ts.openwall.com
Subject: Re: __MUSL__ macro
On Fri, Jul 07, 2023 at 08:14:11AM +0100, Alastair Houghton wrote:
> On 6 Jul 2023, at 13:17, Alex Xu <alex_y_xu@...oo.ca> wrote:
> >
> >> Examples include the use of `union`s in `pthread_mutex_t` et al
> >> (which means that we can’t write a C++ `constexpr` function that
> >> returns one, even if all it does is return
> >> `PTHREAD_MUTEX_INITIALIZER`),
> >
> > The issue is that some of the members are volatile, not the union
> > itself.
>
> ....
>
> Arguing about the details of individual issues is an unnecessary
> distraction, honestly.
Except here it's really not, because the example you brought up where
you couldn't do detection was where your code was doing something very
wrong.
If you can fix your code not to do that wrong thing, it can be fixed
not to do it anywhere.
If you can't, knowing it's "not going to work because you're on
__MUSL__" does not help you. The compiler error is just as good.
> They were just OTOH examples of oddities that
> we’ve come across so far, and yes, I agree that in some cases there
> are potentially better fixes for them than preprocessor shenanigans
> - and where those are available I’m totally onboard with doing that
> instead, because I *entirely agree* that it’s better to avoid a huge
> mass of `#if` conditions in code. There’s a very good chance that
> any I add in the various places I might be interested in adding them
> will end up being my responsibility to maintain, so that, if nothing
> else, is a good motivation for minimising them.
>
> >> or the fact that `dladdr()` is a no-op when statically linked.
> >
> > When statically linked, the dynamic linking interface doesn't work at
> > all though? And furthermore, even if it did, what would it return? If
> > you're (once again) trying to do stack traces manually, try libunwind?
>
> :-D Oh, the irony. One of the places where this behaviour turns out
> to be a problem is *in the tests for libunwind*. (That can be solved
> in another way without resorting to macros, however.)
That dladdr is a no-op rather than always returning the single
static-linked object is a bug that would be worth reporting. Having
someone leave it unreported and instead hard-coding "musl dladdr
doesn't work" is not in our interests.
> > I don't understand, don't you know at compile time whether you're
> > linking statically or dynamically?
>
> Not always, no (see situation 2 below).
>
> > Configure-time checks for specific functionality are a standard part of
> > writing portable C code. Preprocessor checks for specific platforms lead
> > to ifdef swamps that are still not portable to any platforms not
> > initially considered.
>
> There are two situations where the lack of macros is absolutely a
> problem and there isn’t a sane workaround.
>
> 1. You’re cross compiling and the thing you’re interested in is
> *runtime* behaviour, so configure-style checks simply aren’t an
> option. In a cross-compilation situation the only thing they can
> test is that a program will *build*; they can’t test its behaviour
> since you don’t necessarily have anywhere to run it.
>
> 2. You’re in a header-only library, particularly one where the final
> environment you’re running in wasn’t available at whatever
> configuration time you had, assuming you had one at all. A really
> good example of this is the built-in headers in Clang or GCC, but
> the problem also applies to things like STL or Boost.
In neither of these cases do you want to know "this is musl", which
would at best help you make wrong platform-specific assumptions that
might have been true at the time you wrote the code, but which aren't
true later when someone is using it.
Almost every single time somebody has made a big deal about requesting
__MUSL__, whatever it was they wanted to do would have broken on a
later, if not the very next, version of, musl, because what they were
really getting at was that something they wanted to use didn't work
the way they hoped (often because of a bug or extended functionality
that wasn't yet implemented but was reasonable to implement) and they
were trying to hard-code their idea that "musl doesn't work" rather
than "find out if this thing I want to use is available".
I already have a proposal for a *granular* version of the latter, that
doesn't depend on hard-coding assumptions about particular
implementations/versions, initially posted in the libc-coord thread at
https://www.openwall.com/lists/libc-coord/2020/04/22/1. Unfortunately,
while everyone seems to agree "this is a good idea", nobody is rushing
to actually do it. Proposals for an initial list of what to include
here, that could be reviewed and pruned, would be a lot more useful
than re-proposing something that's been rejected as harmful multiple
times already.
Rich
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.
