From: tr.17687@z991.linuxsc.com   
      
   Keith Thompson  writes:   
      
   > Tim Rentsch  writes:   
   >   
   >> Keith Thompson  writes:   
   >   
   > [...]   
   >   
   >>> The  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   
   >>>  or in .  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    
   >>   
   >>     #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.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)