Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: _BitInt(N) Date: Mon, 01 Dec 2025 12:42:52 -0800 Organization: None to speak of Lines: 57 Message-ID: <87pl8y7x2r.fsf@example.invalid> References: <10dajlh$ko3c$1@dont-email.me> <10fv40v$1f7a2$1@dont-email.me> <87ms4c4bom.fsf@example.invalid> <10g08vm$1us25$1@dont-email.me> <10g1et7$2bmus$1@dont-email.me> <10g1j7h$2deh9$1@dont-email.me> <10g1qq9$2f8lb$4@dont-email.me> <10g28gm$2mf9s$1@dont-email.me> <10g2f2d$2oufq$1@dont-email.me> <10g2m3v$2s5sa$1@dont-email.me> <10gfkqd$19n2d$1@paganini.bofh.team> <10gftqi$3qhkg$1@dont-email.me> <87sedw9wjh.fsf@example.invalid> <10gga8k$3v646$1@dont-email.me> <10gghbg$3htol$4@dont-email.me> <10gheka$bgvr$1@dont-email.me> <10ghu7d$3htol$5@dont-email.me> <10gi0ep$i4fi$1@dont-email.me> <10gjqts$17nkj$1@dont-email.me> <875xaq9m51.fsf@example.invalid> <10gknaj$1io6u$2@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Mon, 01 Dec 2025 20:42:53 +0000 (UTC) Injection-Info: dont-email.me; posting-host="8213f2dfee378269bbe79a5548f849a1"; logging-data="1754594"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/GEJ0nrNuvQu6TSIk7YRW+" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:EYa+wkYscQHYSOP58LyfU+0IB9o= sha1:CJoWSj0JfsgHX11QLdZmuYarPLw= Xref: csiph.com comp.lang.c:395643 David Brown writes: > On 01/12/2025 17:56, Keith Thompson wrote: >> David Brown writes: >> [...] >>> (I am not entirely sure, but I think it is standards-conforming for an >>> implementation to haev BITINT_MAXWIDTH set to 64 and support all >>> _BitInts up size 64, and then also support _BitInts of multiples of 64 >>> thereafter. Use of _BitInt greater than BITINT_MAXWIDTH is UB in the >>> standard - so an implementation can choose to give that a defined >>> behaviour for specific sizes.) >> [...] >> No, _BitInt(N) where N > BITINT_MAXWIDTH is a constraint violation. >> N3220 6.7.3.1p2 ("Constraints") : >> >> The parenthesized constant expression that follows the _BitInt >> keyword shall be an integer constant expression N that specifies >> the width (6.2.6.2) of the type. The value of N for unsigned >> _BitInt shall be greater than or equal to 1. The value of N >> for _BitInt shall be greater than or equal to 2. The value of >> N shall be less than or equal to the value of BITINT_MAXWIDTH >> (see 5.2.5.3.2). >> >> As I mentioned before, there's a proposal for C2y to allow >> signed _BitInt(1). >> >> Of course an implementation could do what you suggest as an >> extension. > > Yes, of course - violating a constraint is UB, but it also requires a > diagnostic. I'd place a very different emphasis on that. Violating a constraint requires a diagnostic, which needn't necessarily be fatal. If an implementation chooses to accept the code anyway, the resulting behavior is probably undefined (though the standard doesn't say so explicitly). > So while an implementation could implement a limited > selection of _BitInt's larger than BITINT_MAXWIDTH, if it is to > conform to the C standards it would have to at least give a warning > message when you used these _BitInt's. As an extension (perhaps > enabled by a flag), it could then suppress such diagnostics. Suppressing mandatory diagnostics would not be an "extension" in the way that term is defined by the standard. It would simply be a failure to conform to the standard. Of course non-conforming C-like compilers exist (like gcc in its default mode), and that's not necessarily a bad thing. But given that several compilers have already implemented bit-precise integer types *without* either allowing N > BITINT_MAXWDITH or disallowing "odd" values, I don't think it will be an issue in practice. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */