mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Bruno Haible <bruno@clisp.org>
To: Rich Felker <dalias@libc.org>
Cc: "Dmitry V. Levin" <ldv@altlinux.org>, musl@lists.openwall.com
Subject: Re: [musl] Re: OS detection wrong on Alpine Linux 3.10
Date: Tue, 22 Sep 2020 22:18:19 +0200	[thread overview]
Message-ID: <5868317.9r8Qd0VG7H@omega> (raw)
In-Reply-To: <20200922184610.GI3265@brightrain.aerifal.cx>

[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/


  reply	other threads:[~2020-09-22 20:18 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4768019.hHWyC0TzgU@omega>
2020-09-20 10:12 ` Dmitry V. Levin
2020-09-20 11:19   ` Bruno Haible
2020-09-20 12:18     ` Ariadne Conill
2020-09-20 13:56     ` Szabolcs Nagy
2020-09-20 17:14       ` Rich Felker
2020-09-20 19:21         ` Bruno Haible
2020-09-20 20:58           ` Hadrien Lacour
2020-09-21  6:53           ` A. Wilcox
2020-09-21 11:46             ` Florian Weimer
2020-09-22 18:46           ` Rich Felker
2020-09-22 20:18             ` Bruno Haible [this message]
2020-09-22 20:33               ` Jeffrey Walton
2020-09-22 20:39             ` Jeffrey Walton
2020-09-22 21:04               ` Laurent Bercot
2020-09-22 21:17                 ` Jeffrey Walton
2020-09-23  8:49                   ` Laurent Bercot
2020-09-23 13:13                     ` James Y Knight
2020-09-23 16:08                       ` Rich Felker
2020-09-23 16:16                         ` Jeffrey Walton
2020-09-23 16:26                           ` Ariadne Conill
2020-09-23 16:57                             ` Jeffrey Walton
2020-09-23 16:36                           ` Rich Felker
2020-09-20 12:19   ` Ariadne Conill

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5868317.9r8Qd0VG7H@omega \
    --to=bruno@clisp.org \
    --cc=dalias@libc.org \
    --cc=ldv@altlinux.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).