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.  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 . 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  Test case: https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=tests/test-setlocale_null-mt-all.c  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.