[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200922184610.GI3265@brightrain.aerifal.cx>
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 [1] 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.
