Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: _BitInt(N) Date: Sat, 20 Dec 2025 18:22:11 -0800 Organization: None to speak of Lines: 42 Message-ID: <87v7i0fub0.fsf@example.invalid> 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> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Sun, 21 Dec 2025 02:22:12 +0000 (UTC) Injection-Info: dont-email.me; posting-host="578dbfb0a0a65f08c1efad4eabbb1e11"; logging-data="2555803"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+fRVCa2agPWviEKpL4Rr+i" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:DiE7dh99lXfb3vl1vFOw7PxsqDM= sha1:IDDRRW2qaJ7GLaH3MiptQdkxOaM= Xref: csiph.com comp.lang.c:395869 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. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */