Re: [musl] __MUSL__ macro

[Alastair Houghton <ahoughton@apple.com>]

On 6 Jul 2023, at 13:17, Alex Xu <alex_y_xu@yahoo.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@port70.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.