Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: "A diagram of C23 basic types" Date: Fri, 11 Apr 2025 13:51:03 -0700 Organization: None to speak of Lines: 59 Message-ID: <87wmbqqv60.fsf@nosuchdomain.example.com> References: <87y0wjaysg.fsf@gmail.com> <8634eebq5w.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Fri, 11 Apr 2025 22:51:08 +0200 (CEST) Injection-Info: dont-email.me; posting-host="c7132c9dc01e9da84b004e8ef39b7407"; logging-data="2731929"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/5tE+WpI5mX6mfxoQgoRsb" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:H+fIE6ke4ssY9pKxHZne+sUwjn8= sha1:UrI+Q40u+Y0dbPTfTN8qP+j8wzE= Tim Rentsch writes: [...] > [*] This statement assumes that a bit-precise type whose width > matches one of the standard integer types is still a distinct type. > I don't know if C23 actually follows that rule. I believe it does. N3301 6.2.5 : A *bit-precise signed integer type* is designated as _BitInt(N) where N is an integer constant expression that specifies the number of bits that are used to represent the type, including the sign bit. Each value of N designates a distinct type. It's explicit that two bit-precise types with different values of N are distinct. It's implicit, I think, that any such types are distinct from other integer types. > Editorial comment: my understanding is that there is an asymmetry > regarding the bit-precise types, in that there is an unsigned > bit-precise type of width 1, but not a signed bit-precise type of > width 1. There is. N3301 6.7.2 : 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.4.2.1). But a bit-field defined as `signed int bf:1` can hold the values 0 and -1 (if I initialize it to 1 it compares less than 0). Incidentally, gcc 15 (pre-release) on my system has BITINT_MAXWIDTH = 65535, and clang (18.1.3 and 21 pre-release) has BITINT_MAXWIDTH = 8388608 (2**23). > Assuming that is so, IMO it is a galactically stupid > omission: a signed bit-precise integer of width 1 would very > naturally hold the two values 0 and -1, which is a useful type to > have in some circumstances, and symmetry would be preserved. > Someone didn't have their Wheaties that morning when that decision > was made. I agree that it's unfortunate, though I don't feel as strongly about it. Something else that I consider unfortunate is that C23 allows bit-fields of types bool, int, signed int, unsigned int, a bit-precise integer type, "or other implementation-defined type". It doesn't require implementations to accept, for example, bit-fields of type unsigned long. Bit-precise types let you have bit-fields of arbitrary large widths, but allowing standard types other than [[un]signed] int would have been easy and useful. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */