[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 22 Sep 2020 22:18:19 +0200
From: Bruno Haible <bruno@...sp.org>
To: Rich Felker <dalias@...c.org>
Cc: "Dmitry V. Levin" <ldv@...linux.org>, musl@...ts.openwall.com
Subject: Re: Re: OS detection wrong on Alpine Linux 3.10
[Dropping config-patches from CC.]
Hi Rich,
> 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
Good. Then maybe the term "legitimate" was too strong...
> 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.
It is good to attempt to document such things. But I doubt anyone can
ever produce a complete documentation of this kind:
* For many system calls, when POSIX specifies an errno X for condition A,
and an errno Y for condition B, then if both A and B apply, often
the implementation is free to return errno X or Y. There are many
system calls and many possible combinations of conditions...
* Is a certain function call multithread-safe or not? For example,
setlocale (..., NULL) is multithread-safe in glibc, but not in
musl libc, macOS, and other platforms. [1]
I know that setlocale is not MT-safe in POSIX, but nevertheless
it is useful for threads in multithreaded programs (that don't use
uselocale()) to be able to query the current locale.
* For iconv(), different platforms implement the conversions slightly
differently [2]. The complete documentation would have to include
the conversion tables (huge!).
> 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).
Correct. And my unit tests may start to fail in this scenario, and I'm
willing to accept this.
Unit tests are different than production code in various ways. One aspect
is the notion of "expected outcome". If a test has a different expected
outcome on glibc than on musl — due to implementation-defined or
implementation-dependent but undocumented behaviour — and suddenly on
glibc systems the outcome changes from the glibc outcome to the musl
outcome, I *do* want to know about it. Even though both outcomes are
valid, a change in outcome potentially indicates a problem.
That is the rationale for distinguishing musl from glibc in a test suite.
And an autoconf test wouldn't help here — because it would just classify
glibc on the other side and not alert me of the potential problem.
> As such, in general, it is specifically NOT SUPPORTED USAGE to hard-code
> these kinds of things. This has been documented in various places
Fair enough. But as a test suite maintainer, my judgement is that it is
more useful to make these "NOT SUPPORTED" distinctions than to allow
the musl behaviour to occur on glibc systems and vice versa.
Bruno
[1] Test case: https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=tests/test-setlocale_null-mt-all.c
[2] https://haible.de/bruno/charsets/conversion-tables/
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.
