[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 07 Jul 2023 15:18:13 +0100
From: Alastair Houghton <ahoughton@...le.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: __MUSL__ macro
On 7 Jul 2023, at 14:53, Rich Felker <dalias@...c.org> wrote:
>
> On Fri, Jul 07, 2023 at 08:14:11AM +0100, Alastair Houghton wrote:
>
>> Arguing about the details of individual issues is an unnecessary
>> distraction, honestly.
>
> Except here it's really not, because the example you brought up where
> you couldn't do detection was where your code was doing something very
> wrong.
In point of fact, I didn’t even try to detect musl in that case and instead changed the code to work differently. So it really is irrelevant and again, I wish I hadn’t mentioned it because now we’re spending time on that rather than talking about the actual issue.
> That dladdr is a no-op rather than always returning the single
> static-linked object is a bug that would be worth reporting. Having
> someone leave it unreported and instead hard-coding "musl dladdr
> doesn't work" is not in our interests.
The bug report instructions appear to say that an email to this list is sufficient. Does this need to be a separate message? I’m quite happy to report it as a bug however you please.
>> 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...
[snip]
>>
>> 2. You’re in a header-only library, ...
[snip]
> In neither of these cases do you want to know "this is musl", which
> would at best help you make wrong platform-specific assumptions that
> might have been true at the time you wrote the code, but which aren't
> true later when someone is using it.
Nevertheless, “this is musl” (or better, “this is musl version x.y”) is a reasonable proxy in the absence of the availability of any finer grained information. I entirely agree that it isn’t perfect, and adding such a test potentially necessitates future maintenance when musl is updated - but that future maintenance is on the owner of the project that added such a test, not on you. Many projects have already made a conscious choice to accept those kinds of tests and the associated maintenance overhead in the context of other libraries and environments. This is definitely a balancing act; explicitly testing for particular functionality is better, on that we agree, but it does have overheads and problems of its own and sometimes it makes sense to try to do things in the preprocessor or with compile-time tests instead of having a complex and often slow configuration step.
Without these kinds of macros being available, it’s difficult to make perfectly reasonable tests (like “don’t use this function when building for musl 1.1.7 because it has a known bug”, or “don’t use this function because it isn’t supported on musl (yet)”), and people will just do what various posts suggest on Stack Overflow, which is far worse because they’re relying on hacky methods of detecting musl that are totally outside of your control.
If it is your position that you are not going to add this, ever, then fine. I’ve made my argument and I think that’s the wrong decision but it’s your choice to make.
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.
