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 10:26:16 -0700 Organization: None to speak of Lines: 29 Message-ID: <87o6q0np3b.fsf@example.invalid> References: <10d5vck$3kufd$1@dont-email.me> <875xc9p674.fsf@example.invalid> <10d7ouh$3rq3g$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Tue, 21 Oct 2025 17:26:17 +0000 (UTC) Injection-Info: dont-email.me; posting-host="b6deab9818bdf1e4b3b91d54315c2c46"; logging-data="98923"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18VWO+kY89piNpllsxqU7cf" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:VSF80zJr6yqzlBTfBEJ6AjzpdDg= sha1:h6jXNlx9c2hWvKj/C43nYlllg2A= Xref: csiph.com comp.lang.c:394633 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? 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. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */