mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Markus Wichmann <>
Subject: Re: [musl] setlocale() behaviour
Date: Wed, 19 Jul 2023 18:51:12 +0200	[thread overview]
Message-ID: <ZLgUgK+5E+UuEPfq@voyager> (raw)
In-Reply-To: <>

Am Wed, Jul 19, 2023 at 09:30:08AM +0100 schrieb Alastair Houghton:
> Hi there,
> Presently, musl’s setlocale() function essentially always succeeds, even if it doesn’t actually have data for the requested locale. I note the previous message to the list in 2017
> <>
> discussing potential solutions, but unless I’m much mistaken nothing has really changed in the code?
> This has come up because the test rig for libc++ tries to detect which locale data is installed so that it can run its own locale support tests (it’s trying to test the C++ locale support that it has constructed atop the C library’s underlying locale support).  If, for instance, you don’t have data for fr_FR installed, libc++ won’t run test cases that rely on that data.  On other C library implementations, that’s easy because setlocale() will return NULL in such a case, but musl doesn’t do that - instead, it sets up a copy of C.UTF-8, names it fr_FR and sets that as the current locale :-(
> Kind regards,
> Alastair.

Well, you must not depend on implementation internals. According to
POSIX, the form of the locale environment variables and the strings to
be plugged into setlocale() (except for "POSIX", "C", "", and the null
pointer) are implementation-defined, and musl defines that absolutely
any name is supported and is a copy of C.UTF-8 (again, except for
"POSIX" and "C"). The name handed in must be returned back out again for
gettext to work.

POSIX talks about the form of those variables in the XSI extension, but
only such that it allows variables to have that form (that being
lang_COUNTRY.codeset@modifier), and the precise meaning is again left to
the implementation.

What do the test cases for libc++ depend upon that is not fulfilled
without the localization data?


  reply	other threads:[~2023-07-19 16:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-19  8:30 Alastair Houghton
2023-07-19 16:51 ` Markus Wichmann [this message]
2023-07-19 17:10   ` Alastair Houghton
2023-07-21 10:48     ` Alastair Houghton

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:

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

  git send-email \
    --in-reply-to=ZLgUgK+5E+UuEPfq@voyager \ \ \

* 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

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).