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.