Re: Possible bug in setlocale upon invalid LC_ALL value

[Rich Felker <dalias@libc.org>]

On Fri, Apr 01, 2016 at 08:47:01PM -0400, Assaf Gordon wrote:
> Hello musl developers,
> 
> I'm testing compilation of GNU coreutils on Alpine Linux 3.3.3 (linux kernel 4.1.20, musl-1.1.12-r3).
> 
> I think I've encountered a problem in musl, where using setlocale with invalid locale name returns the invalid locale instead of a known locale.
> example:
> 
>    $ LC_ALL=missing ./myprogram
> 
> If myprogram calls setlocale(LC_ALL,""),
> then musl sets the internal locale despite being invalid value.
> later, checking the locale for a specific category (e.g. LC_COLLATE) will return 'missing' instead of 'C' .
> 
> 
> The relevant POSIX clause is this:
>  http://pubs.opengroup.org/onlinepubs/9699919799/functions/setlocale.html
>  "[...] If the value of any of these environment variable searches yields a locale that
>   is not supported (and non-null), setlocale() shall return a null pointer and the global
>   locale shall not be changed."
> 
> Below is a short C program demonstrating the issue, with example output from various OSes.

This is intentional. All locale names are valid under musl, and those
which don't have any particular definition are just aliases for
C.UTF-8. The alternative would be that UTF-8 support breaks whenever
LC_* vars are set but locales are not installed/configured, which
would pretty much _always_ be the case when running a static-linked
standalone binary on a non-musl-based system (where LC_* are probably
set to something the main host libc recognizes).

One possibility if this behavior is problematic would be to only
consider names without their own definitions as aliases for C.UTF-8
when MUSL_LOCPATH is not set. However I think we'd need to see a
strong motivation for doing that, since it seems like it would be
worse behavior in some ways, especially when using LC_MESSAGES set to
a language for which you don't have a locale installed.

Rich