Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.std.c Subject: Re: bit-fields of type unsigned long and unsigned long long Date: Tue, 22 Jun 2021 11:17:39 -0700 Organization: None to speak of Lines: 56 Message-ID: <8735t9yda4.fsf@nosuchdomain.example.com> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="79e89645a6b772e4af8a6df232d6e9d5"; logging-data="29402"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18j3ghaFMcDS59vlYAXQpVK" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:abjrUx7Q0MCROmSMSmLfsHsgT8c= sha1:hzPt9o0o8zzhfWY0NwQsHBk2Cjc= Xref: csiph.com comp.std.c:6225 David Brown writes: > On 22/06/2021 16:49, Philipp Klaus Krause wrote: >> 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. > > The standard /does/ support them - it simply does not mandate that an > implementation supports them. It's good to be accurate in your wording > for a proposal like that. In the proposal, I suggest: This adds unsigned long and unsigned long long to the +required+ supported types for bit-fields. > In my own code, I don't believe I have ever had need for types longer > than "unsigned int" in bitfields - though I have certainly used the type > "uint32_t" which happens to be "unsigned long" on several targets even > though "unsigned int" is the same size. > > But I have a lot more use of smaller integer types. And I use > enumerated types in bitfields too, though these usually require a > minimum size matching "int" (unless you use compiler-specific extensions > to change that). > > I would suggest that it is pointless to add to the list of types > mandated in the C standard here. Rather, it should simply say that a > bit-field shall have "an integer type". That covers all sizes, shorter > than int as well as longer, signed as well as unsigned. After all, > pretty much any serious modern C compiler will already support all > integer types here. > > And I would also be even happier with "an integer type or enumerated type". I agree. If you're going to mandate support for additional types, why not go all the way? Currently, plain int bit fields have implementation-defined signedness. I'm not a big fan of that rule, but logically it should be extended to bit fields of other integer types specified without a "signed" or "unsigned" keyword -- except that a plain char bit field should IMHO have the same signedness as plain char. Signed bit fields are questionably useful, but support for them is already required, and I'm sure there's code that depends on them. >> Here's a draft of a proposal for that: >> >> http://www.colecovision.eu/stuff/proposal-unsigned-long-bit-field.html "support" is misspelled in the Justification section. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */