Re: [musl] __MUSL__ macro

[Alex Xu <alex_y_xu@yahoo.ca>]

Quoting Alastair Houghton (2023-07-06 06:48:04)
> Hi all,
> 
> Before I start, I’m aware of
> 
>   <https://www.openwall.com/lists/musl/2013/03/29/13>
> 
> but I *still* want to add __MUSL__ (see attached patch).
> 
> Let me explain what we’re doing, why we want it and why we think musl *should* have it.  We’re trying to add support for musl to Swift <https://swift.org <https://swiftlang.org/>> and its attendant core libraries, and there are a number of things about musl that presently differ from other platforms/C libraries we support.

All of these seem to fall at least suspiciously closely to "the usage
case was badly wrong"...

> 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. As I understand, though, constexpr is useful to evaluate certain
expressions at compile time, such as if (x < 10) or int arr[getlen(x)].
You can't do any arithmetic with pthread_mutex_t, and the only valid
value at compile time is PTHREAD_MUTEX_INITIALIZER though, so what is
the use case?

> the fact that it doesn’t have the `d_namlen` member of `struct dirent`

You can use strlen(d->d_name) instead? This seems like exactly the
reason why __MUSL__ should absolutely not be added, because it
incentivizes individual checks for endless platforms instead of writing
portable code. If strlen(d->d_name) is too slow in some context, then an
argument should be made to add d_namlen. glibc even already has a macro
_DIRENT_HAVE_D_NAMLEN that could be used to signal support for this
rather than hardcoding specific musl versions.

> 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?

> I’m aware that there are other solutions for some of these cases - but for instance the `dladdr()` issue is not something you can test at configuration time when cross-compiling, since there’s no way to know what the result would be without running a program on the target system (which you don’t necessarily have available at configuration time in that case).

I don't understand, don't you know at compile time whether you're
linking statically or dynamically?

> Likewise, configuration time tests are slow and  aren’t even a thing in some of the projects we need to add support in, whereas we do generally have the ability to use the preprocessor.

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.

> You might say we should just bite the bullet and add configuration steps to all of the other projects, but that is honestly a non-starter; the owners of those projects are not likely to accept patches to add such a thing, even as a short-term fix, and the patches to do so would be non-trivial in a number of cases also.  In the longer term we don’t want higher level projects to need to do this kind of thing and the lower level ones could in many cases do some kind of configuration time testing, but that’s a longer term goal and it doesn’t help us to add musl support in the interim, which we would like to do.
> 
> I’ve attached a proposed patch that adds `__MUSL__` (set to the major version) and `__MUSL_MINOR__` (set to the minor version) as well as `__MUSL_PREREQ()` (which works the same way `__GLIBC_PREREQ()` does).

In theory, there could possibly be some reason why __MUSL__ could be
useful in some cases. However, your examples appear to be exactly why
__MUSL__ should not be added because it leads to bad code.

Cheers,
Alex.