[Bug locale/17318] [RFE] Provide a C.UTF-8 locale by default

benjaminmoody at gmail dot com sourceware-bugzilla@sourceware.org
Fri Feb 8 21:03:00 GMT 2019


https://sourceware.org/bugzilla/show_bug.cgi?id=17318

--- Comment #11 from benjaminmoody at gmail dot com ---
Something about this doesn't make sense to me.

Sorting Unicode strings by code point is exactly the same as sorting their
UTF-8 representations by unsigned byte value; that's a major part of the
reasoning behind UTF-8.

So, naively, one would expect that strcoll/C.UTF8 == strcoll/C == strcmp, and
strxfrm/C.UTF-8 == strxfrm/C == strlcpy.

Yet that seems not to be the case; on Debian 9, in the C.UTF-8 locale, strxfrm
of "abcd" yields "cdef".  And (unlike the C locale) strcoll is many times
slower than strcmp, and strxfrm is many times slower than strlcpy.

What's the difference?  Is there a requirement somewhere that strcoll must
guard against invalid multibyte sequences, or that strxfrm's output must be a
valid multibyte string?  Are there particular invalid UTF-8 sequences that, for
some reason, *need* to be collated in a particular way?

If not, there's no reason for collation to be non-trivial in UTF-8.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the Glibc-bugs mailing list