Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: _BitInt(N) Date: Tue, 06 Jan 2026 21:51:24 -0800 Organization: A noiseless patient Spider Lines: 39 Message-ID: <864ioyq8bn.fsf@linuxsc.com> References: <10dajlh$ko3c$1@dont-email.me> <10g7oqf$ojir$1@dont-email.me> <10g7ue4$r47b$1@dont-email.me> <10g9a0r$1a895$1@dont-email.me> <10g9fmh$1crf0$1@dont-email.me> <10g9i5e$1dpa3$1@dont-email.me> <10ga0sd$1jb9e$1@dont-email.me> <10ga3hn$1kv34$1@dont-email.me> <10gb1md$203ao$2@dont-email.me> <10gc28l$2c8jt$1@dont-email.me> <875xatbv2s.fsf@example.invalid> <10gddie$2tgu4$1@dont-email.me> <10gf3ci$1pe2v$1@dont-email.me> <861pkpt0rz.fsf@linuxsc.com> <10i7luj$2e4g0$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Wed, 07 Jan 2026 05:51:28 +0000 (UTC) Injection-Info: dont-email.me; posting-host="96c89593a79aadfcc4daf354c711affa"; logging-data="421156"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/uQwpzJ33mbWUsHR+F8aWxbldmlRWqkSk=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:VAOcLWPbxBw/WHUa7DWvkujljkE= sha1:tEogLVcyQZ/0TjgK3EwD0Np2ke8= Xref: csiph.com comp.lang.c:396248 James Kuyper writes: > Tim Rentsch wrote: > >> James Kuyper writes: > > ... > >>> Note: in C2023, the [predefined macro names] section says: "Any other >>> predefined macro names: shall begin with a leading underscore >>> followed by an uppercase letter; or, a second underscore...". For >>> earlier versions of the standard, user code should avoid using such >>> identifiers because they were reserved for all purposes, but that's no >>> longer the case. Now, they should be avoided because they may be >>> pre-defined by the implementation, which means that any attempt to use >>> them might have unpredictable results. >> >> That's right in the sense that if the implementation is unknown then >> unexpected results may occur. However, if the implementation is >> known, then we can find out what results are expected by consulting >> the implementation's documentation for extensions, since any such >> macro name must qualify as an extension, and so much be documented. > > J.5 identifies as extensions only "... predefined macros with names that > do not begin with an underscore." (J.5, J.5.13) That doesn't invalidate what I said. And anyway Annex J is only informative, not normative. > They are not identified as implementation-defined, so there is no > obligation to document them. Let me clarify my earlier comment. An implementation is free to accept almost anything at all, as long as a diagnostic is issued. But any usage[*] that would otherwise be a syntax error or violate a constraint, if accepted without issuing a diagnostic, must be an extension and so must be documented. [*] an ordinary use, not a declaring or defining use.