Re: [musl] __MUSL__ macro

[Rich Felker <dalias@libc.org>]

On Thu, Jul 06, 2023 at 11:48:04AM +0100, Alastair Houghton wrote:
> 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.
> 
> 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 fact that it doesn’t have the
> `d_namlen` member of `struct dirent`, or the fact that `dladdr()` is
> a no-op when statically linked.

This has nothing to do with being on musl. This has to do with writing
semantically incorrect code that does not meet the requirements of the
specification.

pthread_mutex_t is not a value type. It's an object. You cannot
initialize a pthread_mutex_t in one context and copy/assign/return it
to be used somewhere else as a value. Only the actual object
initialized may be used. For example, it may even contain references
to its own address. Whatever implementations you think this works on
on probably to not have a contract to make it work; you're writing to
something that you observed working on your system. And in that case,
once you've read the relevant source, you need to hard-code the unsafe
code to be used *only on that specific implementation and version of
it*, not assume musl is the one doing something odd/different because
you hack doesn't work here.

Rich