Path: csiph.com!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: u8"" c11 c23 Date: Tue, 21 Oct 2025 11:51:40 -0700 Organization: None to speak of Lines: 68 Message-ID: <87jz0onl4z.fsf@example.invalid> References: <10d5vck$3kufd$1@dont-email.me> <875xc9p674.fsf@example.invalid> <10d7ouh$3rq3g$1@dont-email.me> <87o6q0np3b.fsf@example.invalid> <10d8hv0$3rg4$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Tue, 21 Oct 2025 18:51:41 +0000 (UTC) Injection-Info: dont-email.me; posting-host="b6deab9818bdf1e4b3b91d54315c2c46"; logging-data="146143"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+xkTE3ED42qGcDMui+Frvh" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:5+0//+lXoyAv+rMKC19LgyEIiF4= sha1:4mbVn1c4OIdjbl8ShikOuuWRKQo= Xref: csiph.com comp.lang.c:394640 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 */