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:57:01 -0800 Organization: A noiseless patient Spider Lines: 46 Message-ID: <86zf6qothu.fsf@linuxsc.com> References: <10dajlh$ko3c$1@dont-email.me> <10g7aci$icq7$1@dont-email.me> <10g7hm2$lpsu$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> <87v7i0fub0.fsf@example.invalid> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Wed, 07 Jan 2026 05:57:05 +0000 (UTC) Injection-Info: dont-email.me; posting-host="96c89593a79aadfcc4daf354c711affa"; logging-data="421156"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/8ZCH/UAibT6yVKv8g1hqEuWK+UcZBz7k=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:6F5JvrkxhPa2K4Od2Bqi9BWrQ9s= sha1:1OiuOXUJ6VBQ67MH4BtwqHnELN4= Xref: csiph.com comp.lang.c:396249 Keith Thompson writes: > Tim Rentsch writes: > >> 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. >> >> Note by the way that the description in N3220 section 6.10.10.1 >> paragraph 2 makes using #define or #undef be undefined behavior only >> for macro names in the subclause (and also a short list of other >> identifiers). Hence any other predefined macro name may be used, >> definedly, simply by using #undef and then #define for the macro >> name in question (in particular, under C23 rules, but not earlier >> versions of the C standard). > > I don't *think* that all implementation-specific predefined macros have > to be documented -- at least, I'd be surprised if that were the intent. > > For example, I don't think an implementation is required to document its > use of _STDIO_H (the include guard header in the glibc implementation of > ). > > Though it's not normative, N3220 J.5.1 (Common extensions) says: > > Examples of such extensions are new keywords, extra library > functions declared in standard headers, or predefined macros with > names that do not begin with an underscore. I gave a clarifying response to this question in my recent followup to the post from James Kuyper.