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.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25290 invoked from network); 22 Sep 2020 20:18:41 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 22 Sep 2020 20:18:41 -0000 Received: (qmail 15912 invoked by uid 550); 22 Sep 2020 20:18:39 -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 15894 invoked from network); 22 Sep 2020 20:18:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1600805907; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=HquLSGTIlc7L8fV8TNScYZACzemzAnv725K7ZXyptww=; b=fBWVN0B9FSLe+rq3EXT3wyYXAcF92kR14FHqIjxo7ZBZwM859XUzWFrLXpAZc3vja0 xnl9597qUbJGYS/BqQTnKpjAlH3EoSe0XHl/1MslCdqjK4NSJZtKzgpPpp9ULbt3w5kL En+bO3uW1EqriP/Jg8UWfp/exU1G7A0n9HoBNopukQa6Cr90hladTKAznMtRdmMBMr20 88RWRc1BbGC4X2AGI1tY5Re0D/SuFtnmueACQM7lIdEz3ZJklv73ry9ljhDxXe0jGlPx klouA0zjUHamXjcA4ytWE55yMzgUM6U14uVP2HlRnrFQHpo1tlZduTWxjtiC/QWKpLar DyAg== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOGaf0yJVW" X-RZG-CLASS-ID: mo00 From: Bruno Haible To: Rich Felker Cc: "Dmitry V. Levin" , musl@lists.openwall.com Date: Tue, 22 Sep 2020 22:18:19 +0200 Message-ID: <5868317.9r8Qd0VG7H@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-189-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20200922184610.GI3265@brightrain.aerifal.cx> References: <4768019.hHWyC0TzgU@omega> <2533200.g9kxISXj3W@omega> <20200922184610.GI3265@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] 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 =E2=80=94 due to implementation-defined or implementation-dependent but undocumented behaviour =E2=80=94 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 =E2=80=94 because it would just cla= ssify 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 =46air 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=3Dgnulib.git;a=3Dblob= ;f=3Dtests/test-setlocale_null-mt-all.c [2] https://haible.de/bruno/charsets/conversion-tables/