From Newsgroup: comp.lang.c

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

[...]

The <uchar.h> header was introduced in C99. In C99, C11, and C17,
that header defines char16_t and char32_t. C23 introduces char8_t.

There doesn't seem to be any way, other than checking the value of
__STDC_VERSION__ to determine whether char8_t is defined or not.
There are not *_MIN or *_MAX macros for these types, either in
<uchar.h> or in <limits.h>. A test program I just wrote would have
been a little simpler if I could have used `#ifdef CHAR8_MAX`.

[...]

Since C23 defines char8_t to be the same type as unsigned char,
it seems better to just define it when it isn't there:

#include <limits.h>

#if CHAR_BIT == 8 && __STDC_VERSION__ < 202311
typedef unsigned char char8_t;
#endif

Yes. And the test for CHAR_BIT may not be necessary, depending on
the programmer's intent. char8_t is the same type as unsigned char
even if CHAR_BIT > 8.

That's humorous. It's like a name designed to be confusing or
misleading. But thank you for the information, I wouldn't have
guessed it.

Similarly, char16_t and char32_t are the same type as
uint_least16_t and uint_least32_t, respectively.

Kind of weird, but at least it's consistent, and it explains why
char8_t is the same as unsigned char. Then again, why not
uint_least8_t? Has C23 changed to the point where unsigned char
and uint_least8_t have to be the same type? My recollection is
that in earlier editions of the C standard it is possible, even
if unlikely, for these types to be distinct.
--- Synchronet 3.21a-Linux NewsLink 1.2