This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Should glibc provide a builtin C.UTF-8 locale?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Paul Eggert <eggert at cs dot ucla dot edu>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 12 Feb 2015 10:15:46 -0500
- Subject: Re: Should glibc provide a builtin C.UTF-8 locale?
- Authentication-results: sourceware.org; auth=none
- References: <54DB8243 dot 3050903 at redhat dot com> <54DBFA8D dot 8030107 at cs dot ucla dot edu> <54DC0546 dot 3080102 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1502121207010 dot 10529 at digraph dot polyomino dot org dot uk>
On 02/12/2015 07:12 AM, Joseph Myers wrote:
> On Wed, 11 Feb 2015, Carlos O'Donell wrote:
>
>> When I say "like C" I mean that setting "C.UTF8" in LC_ALL would
>> ignore LANGUAGE, as is required when setting LC_ALL to "C".
>
> "Like C" could also mean that ASCII characters (and probably all
> characters) are collated in code-point order (so, for example, all
> uppercase ASCII letters come before all lowercase). Or do you think the
> right way to achieve that minimal extension of the C locale to UTF-8 is to
> set only LC_CTYPE and not LC_COLLATE or LC_ALL?
That's an open question. I expect that your instinct is correct and that
we should collate in code-point order. There should be some deterministic
ordering such that low-level sorting utilities work reliably.
Cheers,
Carlos.