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: Sun, 21 Dec 2025 22:48:57 -0800 Organization: A noiseless patient Spider Lines: 26 Message-ID: <86ldivroyu.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> <20251220181805.887@kylheku.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Mon, 22 Dec 2025 06:48:59 +0000 (UTC) Injection-Info: dont-email.me; posting-host="a7f5d1e51a9a8827e6b0e0c25bf5c54b"; logging-data="3477400"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18CMlZapodAc8rEH7Vvi2oE8O1pzEaivf8=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:sEOrKzuZxdFh2edc+e72NihhhNI= sha1:Xx0N5wHETVawFghWFNKhYuU0t78= Xref: csiph.com comp.lang.c:395876 Kaz Kylheku <046-301-5902@kylheku.com> writes: > On 2025-12-20, Tim Rentsch wrote: > >> 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). > > If that interpretation is accurate, it is a serious problem. Yes, very serious. I suspect the change is simply an oversight on the part of those responsible for the wording in the C23 standard. > The implementation must be prepared for the situation that any of its > internal macros are undefined, or undefined and redefined. > > That means that other macros cannot rely on those macros. > Some documented macro foo() cannot rely on a __foo_impl() > macro because the program could #undef that. Probably there are other ways to work around the problem, but it does seem better just to avoid the problem altogether by forbidding definitions (or #undef) of any reserved identifiers, including macro names.