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: VAX Date: Tue, 06 Jan 2026 21:14:48 -0800 Organization: A noiseless patient Spider Lines: 57 Message-ID: <86cy3mqa0n.fsf@linuxsc.com> References: <0c857b8347f07f3a0ca61c403d0a8711@www.novabbs.com> <2025Jul30.075918@mips.complang.tuwien.ac.at> <2025Aug1.191648@mips.complang.tuwien.ac.at> <106jvc3$qan0$1@dont-email.me> <106kh0k$18ipb$1@paganini.bofh.team> <2025Aug3.185110@mips.complang.tuwien.ac.at> <106otf6$1sov2$1@dont-email.me> <106p4k6$1u13o$1@dont-email.me> <20250804121938.0000122a@yahoo.com> <2025Aug4.140932@mips.complang.tuwien.ac.at> <2025Aug4.165141@mips.complang.tuwien.ac.at> <20250804182839.00000600@yahoo.com> <87sei7do4g.fsf@example.invalid> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Wed, 07 Jan 2026 05:14:54 +0000 (UTC) Injection-Info: dont-email.me; posting-host="96c89593a79aadfcc4daf354c711affa"; logging-data="421156"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/w8HerapivpZ/eGzIq8j7kwcoW1FhYXdg=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:Ch08saVjr0ld54nagQFkV7nTIZU= sha1:BEoJmgv6zD+SFz9aGXwrSNYHsRU= Xref: csiph.com comp.lang.c:396246 Keith Thompson writes: > Michael S writes: > >> On Mon, 04 Aug 2025 12:09:32 GMT >> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > > [...] > >>> typedef ump unsigned _BitInt(65535); > > The correct syntax is : > > typedef unsigned _BitInt(65535) ump; > >>> ump sum3(ump a, ump b, ump c) >>> { >>> return a+b+c; >>> } > > [...] > >> 1. Both gcc and clang happily* accept _BitInt() syntax even when >> -std=c17 or lower. Is not here a potential name clash for existing >> sources that use _BitInt() as a name of the function? I should think >> more about it. > > In C17 and earlier, _BitInt is a reserved identifier. Any attempt to > use it has undefined behavior. [...] Not so. The C standard says if a program declares or defines a reserved identifier (in a context where it is reserved) then the behavior is undefined. The C standard does /not/ say that simply using (as opposed to declaring or defining) a reserved identifier has undefined behavior (in any context). The C23 standard is different, but I believe what it says is consistent with the previous paragraph. Furthermore it is always possible to use any reserved identifier in a way that has defined behavior, as for example: #include #define XX(a) X(a) #define X(a) #a #define show(a) printf( "The id %s expands to %s\n", X(a), XX(a) ) int main( int argc, char *argv[] ){ show( _BitInt ); return 0; } This program works without complaint under all of C90, C99, C11, and C17.