[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