From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 20565 invoked from network); 7 Jul 2023 13:53:17 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 7 Jul 2023 13:53:17 -0000 Received: (qmail 30330 invoked by uid 550); 7 Jul 2023 13:53:15 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 30295 invoked from network); 7 Jul 2023 13:53:12 -0000 Date: Fri, 7 Jul 2023 09:53:02 -0400 From: Rich Felker To: Alastair Houghton Cc: musl@lists.openwall.com Message-ID: <20230707135302.GF4163@brightrain.aerifal.cx> References: <309EDCC9-2402-46B5-BDBD-B96677E470DD@apple.com> <168864586814.64499.13397704850676744237@alexps.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] __MUSL__ macro On Fri, Jul 07, 2023 at 08:14:11AM +0100, Alastair Houghton wrote: > On 6 Jul 2023, at 13:17, Alex Xu 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. 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. If you can fix your code not to do that wrong thing, it can be fixed not to do it anywhere. If you can't, knowing it's "not going to work because you're on __MUSL__" does not help you. The compiler error is just as good. > 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.) 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. > > 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. 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. Almost every single time somebody has made a big deal about requesting __MUSL__, whatever it was they wanted to do would have broken on a later, if not the very next, version of, musl, because what they were really getting at was that something they wanted to use didn't work the way they hoped (often because of a bug or extended functionality that wasn't yet implemented but was reasonable to implement) and they were trying to hard-code their idea that "musl doesn't work" rather than "find out if this thing I want to use is available". I already have a proposal for a *granular* version of the latter, that doesn't depend on hard-coding assumptions about particular implementations/versions, initially posted in the libc-coord thread at https://www.openwall.com/lists/libc-coord/2020/04/22/1. Unfortunately, while everyone seems to agree "this is a good idea", nobody is rushing to actually do it. Proposals for an initial list of what to include here, that could be reviewed and pruned, would be a lot more useful than re-proposing something that's been rejected as harmful multiple times already. Rich