Re: [musl] setlocale() behaviour

[Markus Wichmann <nullplan@gmx.net>]

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
>
> <https://www.openwall.com/lists/musl/2017/11/08/1>
>
> 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?

Ciao,
Markus