Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.std.c Subject: Re: bit-fields of type unsigned long and unsigned long long Date: Wed, 23 Jun 2021 10:53:11 -0700 Organization: A noiseless patient Spider Lines: 42 Message-ID: <86fsx8bh88.fsf@linuxsc.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="4ed2f4a6c1ddc5d4ab0e781c2b6d44da"; logging-data="21178"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18NbRAWo0NBCFRgaaZKdu+RxJRk7atdkJc=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:G5tivD2/Rsa/WgpQtRh8E2oiy5g= sha1:EmeK9hSPsFqnQArparGZomFvG7k= Xref: csiph.com comp.std.c:6236 Philipp Klaus Krause writes: > Since bit-fields of type unsigned long and unsigned long long are > useful, commonly suppoted by implementations, and commonly used, I'd > like to see the standard support them. > > Here's a draft of a proposal for that: > > http://www.colecovision.eu/stuff/proposal-unsigned-long-bit-field.html Here is a possible (and simpler) alternative. Type specifier for bit-fields is _Bool, int, signed, or unsigned (with signed int and unsigned int being synonymous with signed and unsigned, respectively). Bit-fields of type _Bool act just like they do now. Bit-fields of type int are either the same as an unsigned bit-field or the same as a signed bit-field, with the choice being implementation-defined, just like they are now. Bit-fields of types signed and unsigned may use widths up to the widths of intmax_t and uintmax_t, respectively. The type of a signed bit-field is the first of signed, long, long long, and intmax_t, that is wide enough to hold all the possible values of the bit-field. The type of an unsigned bit-field is the first of unsigned, unsigned long, unsigned long long, and uintmax_t, that is wide enough to hold all the possible values of the bit-field. For compatibility with current integer promotion rules, an access for an unsigned bit-field whose range of possible values are all representable within the range of signed int yields a value that has been promoted to type signed int, just like such things are done now. In all other cases the type of a bit-field access is the type of the bit-field, as stated above. (Personally I like this approach better than allowing different integer types as bit-field specifiers.)