[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 07 Jul 2023 08:14:11 +0100
From: Alastair Houghton <ahoughton@...le.com>
To: musl@...ts.openwall.com
Subject: Re: __MUSL__ macro
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. 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.)
> 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.
> On 6 Jul 2023, at 17:26, Szabolcs Nagy <nsz@...t70.net> wrote:
>
> the problem is not that the usage is wrong, but that
> these can change between different versions of musl
> (within abi constraints) and header changes can be
> backported by distros.
>
> so __MUSL__ cannot solve these issues.
That’s why `__MUSL__` should evaluate to the major version number and `__MUSL_MINOR__` to the minor version number, and why we should have `__MUSL_PREREQ()`, just like Glibc, which, by the way, has the exact same problems you raise (things can change, and distros can backport things).
If some third-party package wishes to test `__MUSL__`, it’s up to the maintainers of that package to make sure that they perform appropriate version checks. And yes, if they’re working around a bug or musl changes its behaviour to add a feature that wasn’t there, they may have to update their code from `#ifndef __MUSL__` to `#if __MUSL_PREREQ(x,y)` or similar. Package maintainers that make these kinds of tests are used to having to do that and if they’re willing to accept macro-based tests, then they’ll be well aware of the cost of doing so.
The alternative to adding these isn’t “lots of non-buggy support for musl”. It’s “less support for musl”, because there are awkward corner cases where it just isn’t possible to do things any other way.
Kind regards,
Alastair.
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.
