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

[James Youngman <jay@gnu.org>]

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.  Certainly, the POSIX definition of setlocale() does not
require that the implementation should return non-NULL in the case of
a failure.

James.