Bug#286717: glibc: locale initialisation failure if cannot mmap locale.alias

[GOTO Masanori <gotom@debian.or.jp>]

At Fri, 14 Jan 2005 12:43:24 +0000,
James Youngman wrote:
> On Fri, Jan 14, 2005 at 10:29:14AM +0900, GOTO Masanori wrote:
> 
> > I think the point is if VM is limited, the first sort works as LANG=C:
> > 
> > 	( ulimit -v 1800 >/dev/null ; sort < testfile ) | sort -c
> > 
> > Thus, it should work:
> > 
> > 	( ulimit -v 1800 >/dev/null ; sort < testfile ) | LANG=C sort -c
> > 
> > Looking at the first sort with ltrace command, setlocale() in sort
> > returns as "C" locale.  The current glibc works as follows: when the
> > 2nd argument of setlocale() is "", and setting LC_ALL is failed, we
> > should try to the next environment variable like LANG.  But memory is
> > limited, so all environment variable is not treated, then it falls
> > back to C locale.  So the return value becomes "C".  Using "" is
> > implementation bahavior, so I think the current behavior is not wrong.
> > Thus, this is not bug of either glibc or coreutils.  Paul, how do you
> > think about this?
> 
> There is an argument that if sort cannot produce output which is
> correctly sorted according to its locale settings, it should return
> non-zero.  Presumably, it would need to test the return value of
> setlocale() to do that, and setlocale() would need to return NULL in
> this case.

setlocale() in SUSv3 said:

    Setting all of the categories of the locale of the process is
    similar to successively setting each individual category of the
    locale of the process, except that all error checking is done
    before any actions are performed. To set all the categories of the
    locale of the process, setlocale() is invoked as:

    setlocale(LC_ALL, "");

    In this case, setlocale() shall first verify that the values of
    all the environment variables it needs according to the precedence
    rules (described in the Base Definitions volume of IEEE Std
    1003.1-2001, Chapter 8, Environment Variables) indicate supported
(1) locales. 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 locale of the
(2) process shall not be changed. If all environment variables name
    supported locales, setlocale() shall proceed as if it had been
    called for each category, using the appropriate value from the
    associated environment variable or from the implementation-defined
    default if there is no such value.

If the locale name search is succeeded (condition (1) is not matched),
setlocale() could be succeeded using the implementation defined
default - glibc uses C (condition (2) is matched).  One drawback of
setlocale() is it does not return any error number - we cannot deliver
any error type for example ENOMEM.  We don't distinguish between the
target locale missing and error condition.

Regards,
-- gotom