[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZKge4q4QjB7j0ooB@voyager>
Date: Fri, 7 Jul 2023 16:19:14 +0200
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: __MUSL__ macro
Am Fri, Jul 07, 2023 at 02:14:30PM +0100 schrieb Alastair Houghton:
> This is a somewhat irrelevant distraction and I rather wish I hadn’t
> mentioned that as an example of odd behaviour. I’m well aware that
> you cannot copy or assign `pthread_mutex_t` values in general (and I
> understand the reasons why).
>
> Please can we instead focus on the issue of whether or not musl should
> have `__MUSL__` and `__MUSL_MINOR__`.
>
The counter-examples are not irrelevant. That is precisely the point.
Nobody advocating for implementation identification macros has so far
given a valid reason to do so. Every single one so far has turned out to
be spurious. Well, I tell a lie, there is one case with a shadow of
reason behind it: Header-only libraries. But maybe the problem with
those is trying to be a header-only library.
If you have different implementations with different runtime behavior,
check whether the behavior is acceptable from the specification. If it
is, write code that can accept the behavior. If it is not, write a bug
report.
Very often I am astonished that the problem presented is claimed to have
the __MUSL__ macro as a solution. I am reminded of a Stack Overflow
question where someone wanted to identify musl, because musl doesn't
have a trustworthy vfork(). Pressed on what exactly he meant, the poster
said that depending on version and architecture, calling vfork() with
musl actually results in it calling fork(). OK, that was his concern.
His solution? If he found he was running on Apple or musl, he wanted to
call fork() instead of vfork(). Why he would not just always call
vfork() if the claimed untrustworthy behavior was also his remedy is a
question the guy skillfully avoided an answer to.
In your case, apparently there is a way to deal with failing dladdr().
So why don't you put the code for that in the failure path for the call,
instead of into "#ifdef __MUSL__"? That way, even unknown
implementations would be supported.
For header-only libraries, the customer could configure them at build
time. I have so far not figured out why people that write programs for a
living cannot be expected to fill out a config.h template. There was a
person here before who wanted a macro to identify that qsort_r() is
available, and I told him much the same thing, and never got a
satisfactory answer to the above query. Also, he already had his own
fallback sorting algorithm, so the portable solution was just to call
that, and then the whole need evaporated.
I remain in staunch opposition to identification macros, because those
have so far always - no matter how benevolent they might have seemed at
the beginning - lead to #ifdef hell of levels Dante couldn't dream of.
They lead to people writing bad code and making bad assumptions.
None of this matters one bit, because Rich is God as far as musl is
concerned, and he has not weighed in yet. However, in the past he has
spoken out against these macros, and I doubt your arguments have
convinced him. They haven't convinced me, at any rate.
Ciao,
Markus
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.
