Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
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 <tr.17687@z991.linuxsc.com> 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 */