Re: wcscoll does not collate properly, even en_US

[Rich Felker <dalias@libc.org>]

On Sun, Nov 26, 2017 at 03:33:00PM -0600, A. Wilcox wrote:
> Hi.
> 
> My understanding is that musl does not want to support collation in
> non-English languages (at least, not yet), but collation is supported in
> American English.

I'm not sure where you got that understanding. The information on the
wiki states that proper LC_COLLATE functionality (anything but raw
codepoint order) is intended future functionality but not yet done.
Nowhere in musl is "American English is supported but nothing else is"
an acceptable policy (and as such a hypothetical patch to add
hard-coded LC_COLLATE for American English without a general framework
capable of supporting arbitrary languages would be rejected by me).

> glib's test suite is failing on musl now because the locale code is just
> functional enough to make glib not skip the tests entirely (1.1.16
> failed the 'setlocale is giving us the locale we set back' test), yet
> collation doesn't work.  wcscoll is giving the same result as wcscmp.
> This is wrong; a simple test case is attached.  Run on a glibc machine,
> a FreeBSD machine, and a Solaris machine, it will output:

This is known. kaniini (from Alpine) and others have brought similar
things to my attention and the issue of how current setlocale behavior
affects applications/tests is under discussion in the thread
"setlocale behavior with 'missing' locales". I'd really like further
feedback on it so that the proposed changes don't end up being a worse
problem that we have to revert/throw-away.

While we're on the topic of getting things in a state so that locale
functionality is actually usable, the thread "Bikeshed invitation for
nl_langinfo ambiguities" also needs some attention.

Rich