Re: multibyte C locale

[Albert Cahalan <albert@xxxxxxxxxxxxxxxxxxxxx>]

On Fri, Oct 30, 2009 at 6:03 PM,  <wollman+austin-group@lcs.mit.edu> wrote:
> <<On Fri, 30 Oct 2009 17:46:54 -0400, Glen Seeds <Glen.Seeds@ca.ibm.com> said:

>>> [I wrote:]
>>> Turn it around: of what value is the POSIX locale without such a
>>> requirement?
>
>> The value is considerable, if we can find a way to accommodate UTF-8.
>
> I don't see it.  What's the use case?  I can see a value to
> applications in being able to configure a locale that acts like
> pre-locale Unix and C did; I don't see a value in configuring a locale
> that doesn't behave like traditional Unix, but isn't usefully
> localized either.  ("Traditional Unix" behavior is normally what I
> want pretty much all the time.)

C.UTF-8 would be damn nice. Dealing with UTF-8 text is rather
important these days. Unfortunately, locales like en_US.UTF-8
get all stupid with collating order. 'a' comes after 'Z' damn it!
(that is, U+0061 is a bigger number than U+005A) Possibly
there is some hack with multiple locale variables that will make
things sane, but that's excessively painful for such a common case.

I expect the plain C locale to cover U+0000 through U+00FF,
but it does not. At least with glibc, stuff like U+00E0 fails the
isalpha() test. Ouch, this is broken too.