[<prev] [<thread-prev] [day] [month] [year] [list]
Message-ID: <875x88qr2l.fsf@keithp.com>
Date: Sat, 07 Feb 2026 11:41:38 -0800
From: Keith Packard <keithp@...thp.com>
To: Joseph Myers <josmyers@...hat.com>, libc-coord@...ts.openwall.com
Subject: Re: c8rtowc and wcrtoc8
> I was only commenting on the approach taken for the <stdmchar.h> functions
> that are new in C2y, not the <uchar.h> functions in C23 (of which the
> char16_t and char32_t ones were in C11).
Ooo, thanks for the reference. I should follow the C2Y work more
closely, especially in this area—as noted in N3366, the existing
standard is pretty much unusable for modern application development.
However, it doubles-down on accepting that wchar_t may not hold every
possible code point. I'm only interested in environments where wchar_t
is the same as char32_t and all non-UCS-4/UTF-32 encodings are managed
as multi-byte. Which seems to be a broad set of non-Windows systems at
least? Which is why this proposal is more suitable for extra-lingual
agreements and not as a part of any upcoming C standard...
It also explicitly rejects standardization of intra-Unicode conversion
functions. In my experience, these are often mis-implemented as they
regularly neglect error checking. Having the C library provide
implementations would improve overall code quality. You could make the
same argument for the entire math library; those functions need not be
part of the C standard given their definitions...
In any case, adding a c8state_t* parameter to wcrtoc8 would make these
functions represent the primitive one-at-a-time functions described in
that document as forming the basis of the musl implementation. Perhaps
that's of some use?
--
-keith
Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
