Date: Tue, 22 Sep 2020 14:46:10 -0400 From: Rich Felker <dalias@...c.org> To: Bruno Haible <bruno@...sp.org> Cc: "Dmitry V. Levin" <ldv@...linux.org>, config-patches@....org, musl@...ts.openwall.com Subject: Re: Re: OS detection wrong on Alpine Linux 3.10 On Sun, Sep 20, 2020 at 09:21:48PM +0200, Bruno Haible wrote: > Rich, > > POSIX — like many other standard — allows different implementations to > behave differently. For example, iconv_open() and setlocale() behave > differently in different POSIX-compliant libc implementations. This is > OK. There is nothing wrong with it on either side. > > Unit tests  need to take into account the actual behaviour of the > software. It is normal that a unit test's core function produces a > different result with musl than with glibc. The "expected outcome" > part of the unit test, in this case, needs to be different. This is > an actual, practical need to know whether the config triple ends in > linux-gnu vs. linux-musl. > > > There is one kinda legitimate purpose for detecting specifically musl: > > It is not your role to tell us which code we write is "legitimate" and > which code is not. I am a grown-up programmer. I'm not trying to tell you you're not a grown-up programmer. I'm trying to tell you that the answer to the question you're asking ("is this musl?") is not meaningful for achieving what you presumably want to achieve -- assisting the program using autoconf tests in automatically producing a build that works on the intended host. It's true that implementations have a number of things that are implementation defined, and that the standards specify this as having a documented behavior (which the party reading the documentation can then rely upon). At present musl does not have sufficient documentation in this regard; I began the work of enumerating all the impl-defined behaviors at one point with a goal of documenting them but it was never completed. However, more fundamentally, the notion of "the implementation", in this sense, is specific to one particular version, along with whatever distributor-applied or user-applied patches might be present. That is to say, some of the implementation-defined behaviors may *change between versions* in ways that render a hard-coded assumption that "musl does X" wrong when building against a newer version or even just running against a newer version (assuming dynamic linking). As such, in general, it is specifically NOT SUPPORTED USAGE to hard-code these kinds of things. This has been documented in various places (mailing list, wiki, etc.) over the project's lifetime but should really be written up well as part of the formal documentation. Instead, it's our intent (i.e. musl's supported way of interfacing with implementation-defined behavior) that programs intending to rely on properties that are not well-defined across different implementations should have their build systems perform the appropriate fine-grained tests for what they need to know. Trying to improve the ability for build systems to do this, especially in the cross-compiling case and cases where the test itself would invoke UB, is the topic of this thread on libc-coord: https://www.openwall.com/lists/libc-coord/2020/04/22/1 Rich
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.