From: Keith.S.Thompson+u@gmail.com   
      
   Thiago Adams  writes:   
   > On 10/21/2025 2:26 PM, Keith Thompson wrote:   
   >> Thiago Adams  writes:   
   >>> On 10/20/2025 7:19 PM, Keith Thompson wrote:   
   >> [...]   
   >>>> That raises another issue.   
   >>>> The  header was introduced in C99.  In C99, C11, and C17,   
   >>>> that header defines char16_t and char32_t.  C23 introduces char8_t.   
   >>>   
   >>> I think for all these typedefs related with language concepts, like   
   >>> size_t which is related with sizeof, char8_t which is related with   
   >>> u8"" char16_t u"", char32_t  U""... etc.. should be built-in typedefs.   
   >>>   
   >>> And even others that does not have a association with language   
   >>> features like int16_t.   
   >> By "built-in typedefs", do you mean typedefs that are visible   
   >> without   
   >> a #include?   
   >>   
   >   
   > yes.   
   >   
   >> That would be unprecedented, but I suppose it could work.  But I'm not   
   >> sure it would be all that advantageous.  The type of the result of   
   >> sizeof is some implementation-defined unsigned integer type.  The   
   >>  header merely provides a consistent name for that type.   
   >> I can see that having language features depend (indirectly) on types   
   >> defined in library headers is a bit messy, but I don't think it causes   
   >> any real problems.   
   >>   
   >   
   >   
   > It's not really a problem, but it depends on the includes, which in   
   > turn depend on the preprocessor.   
   >   
   > It seems like the language is partially configured through macros and   
   > typedefs in includes.   
      
   The way I'd describe it is that the type of a sizeof expression is   
   chosen by the compiler, and the definition of size_t in    
   documents that choice and makes it visible to programmers.   
      
   > Some types that have direct relation with the language:   
   >   
   >     typedef typeof_unqual(sizeof(0)) size_t;   
   >     typedef typeof_unqual(((char*)1)-((char*)0)) ptrdiff_t;   
   >     typedef typeof_unqual(u8' ') char8_t;   
   >     typedef typeof_unqual(u' ') char16_t;   
   >     typedef typeof_unqual(U' ') char32_t;   
   >     typedef typeof_unqual(L' ') wchar_t;   
   >     typedef typeof_unqual(nullptr) nullptr_t;   
   >   
   > I think it does not make sense to have to include a file to describe   
   > size_t because we can use sizeof without having to include anything.   
      
   I suppose if I were defining a new language from scratch, I probably   
   wouldn't have those types defined in library headers.  I might have   
   made size_t a keyword, for example.   
      
   One data point: C++ has wchar_t as a keyword, while C defines it as   
   a typedef in .  C++'s wchar_t has the same representation   
   as one of the other integral types, called its underlying type.   
   That could have been a nice approach for C, but I'd say it's too   
   late to fix it, and the benefits aren't worth the cost.   
      
   --   
   Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com   
   void Void(void) { Void(); } /* The recursive call of the void */   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)