[Bug locale/29511] default/C/POSIX locale is 7-bit (127 characters), must be 8-bit (256 characters) since POSIX Issue 7 TC2/Issue 8

["nabijaczleweli at nabijaczleweli dot xyz" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #2 from наб <nabijaczleweli at nabijaczleweli dot xyz> ---
I don't see how that's relevant? The POSIX locale is /not/ US-ASCII: it's
/some/ encoding that contains the PCS and NPCS as the first 128 characters
(this coincides with 7-bit ASCII) /and/ contains mappings from all 256 single
bytes to a character (and back).

This is very obviously listed in the first hunk, which I'll reiterate again:
POSIX.1, Issue 7 TC 2, XBD, 6.2 "Character Encoding" starts with:
  > The POSIX locale shall contain 256 single-byte characters including the
characters in Portable Character Set and Non-Portable Control Characters, which
have the properties listed in LC_CTYPE. 

The bug here isn't "glibc doesn't decode ASCII [0xfa, 0] to my favourite
character", it's "glibc treats POSIX locale as-if it were ASCII" – which it's
not.

From your response it appears you also haven't consulted bug 663 (an oversight
on my part, it seems I only linked it directly in the Debian bug, and here
indirectly): https://www.austingroupbugs.net/view.php?id=663 – it contains a
summary of changes that make the Issue 7 TC 2/Issue 8 POSIX locale
as-described.

POSIX.1, Issue 7 TC 2, XSH, mbrtowc(), ERRORS:
-- >8 --
 [EILSEQ]
    An invalid character sequence is detected. [CX]In the POSIX locale an
EILSEQ error cannot occur since all byte values are valid characters.[/CX]
-- >8 --
(the same text is seen in mbrlen(), mbstowcs(), &c., &c.).

POSIX.1, Issue 7 TC 2, XRAT, XBD, A.6.2 Character Encoding:
-- >8 --
Earlier versions of this standard did not state the requirement that the POSIX
locale contains 256 single-byte characters. This was an oversight; the
intention was always that the POSIX locale should have an 8-bit-clean
single-byte encoding.
-- >8 --

I hope this convinces you that this is not RESOLVED INVALID, but, indeed, a
conformance error.

A different, less messy than the one in my patch (or just making it a KOI-8
variant, which is admittedly the worst one so far), solution I arrived at today
would be to map [0, 0x7F] to [U+0, U+7F] as is done currently and B[0x80, 0xFF]
to C[U+FFFFFF80, U+FFFFFFFF] or C[U+FFFFFF00, U+FFFFFF7F] — I don't think
Unicode will reach that high any-time soon – or to pick a PUA and map to
C[U+100000, U+10007F]/C[U+E080, U+E0FF]/you get the point here – "using glibc"
reasonably fits as a "private agreement between collaborating users".

Changing the CODESET is also, presumably, a given: naively, to "POSIX", I
guess?

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