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:33:08 -0800 Organization: A noiseless patient Spider Lines: 53 Message-ID: <868qeaq963.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> <20250804220315.00007240@yahoo.com> <6859dc0d-f3b5-481b-8ffb-b4c0a722412e@alumni.caltech.edu> <20250804224049.00006937@yahoo.com> <20250805140933.174@kylheku.com> <106vtsh$2uli0$1@dont-email.me> <878qjw6ub8.fsf@example.invalid> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Wed, 07 Jan 2026 05:33:13 +0000 (UTC) Injection-Info: dont-email.me; posting-host="96c89593a79aadfcc4daf354c711affa"; logging-data="421156"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19SmOhxgVnbEWEV4u7wL4zWOGEVFTYujhA=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:3J7MTj4BAUO/y9q/3KGnd/JCSto= sha1:ezrR2jkK8VgKL5FsheOhUdTBVTU= Xref: csiph.com comp.lang.c:396247 Keith Thompson writes: > James Kuyper writes: > >> On 2025-08-05 17:13, Kaz Kylheku wrote: >> >>> On 2025-08-04, Michael S wrote: >>> >>>> On Mon, 4 Aug 2025 15:25:54 -0400 >>>> James Kuyper wrote: >> >> ... >> >>>>> If _BitInt is accepted by older versions of gcc, that means it >>>>> was supported as a fully-conforming extension to C. Allowing >>>>> implementations to support extensions in a fully-conforming >>>>> manner is one of the main purposes for which the standard >>>>> reserves identifiers. If you thought that gcc was too >>>>> conservative to support extensions, you must be thinking of the >>>>> wrong organization. >>>> >>>> I know that gcc supports extensions. >>>> I also know that gcc didn't support *this particular extension* >>>> up until quite recently. >>> >>> I think what James means is that GCC supports, as an extension, >>> the use of any _[A-Z].* identifier whatsoever that it has not >>> claimed for its purposes. >> >> No, I meant very specifically that if, as reported, _BitInt was >> supported even in earlier versions, then it was supported as an >> extension. > > gcc 13.4.0 does not recognize _BitInt at all. > > gcc 14.2.0 handles _BitInt as a language feature in C23 mode, > and as an "extension" in pre-C23 modes. > > It warns about _BitInt with "-std=c17 -pedantic", but not with > just "-std=c17". I think I would have preferred a warning with > "-std=c17", but it doesn't bother me. There's no mention of _BitInt > as an extension or feature in the documentation. An implementation > is required to document the implementation-defined value of > BITINT_MAXWIDTH, so that's a conformance issue. In pre-C23 mode, > since it's not documented, support for _BitInt is not formally an > "extension"; it's an allowed behavior in the presence of code that > has undefined behavior due to its use of a reserved identifier. > (This is a picky language-lawyerly interpretation.) To clarify the last part, undefined behavior is allowed only because a diagnostic was generated. If there were no diagnostic then it would have to be documented as an extension, otherwise the implementation would not be conforming.