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: Wed, 23 Jun 2021 00:39:20 -0700 Organization: None to speak of Lines: 48 Message-ID: <87tulpvxlj.fsf@nosuchdomain.example.com> References: <8735t9yda4.fsf@nosuchdomain.example.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: reader02.eternal-september.org; posting-host="28e7cfb7a9d1bfdd32dfeb115dacde84"; logging-data="21011"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+dzsAGckkdKjHd0dFQLLwi" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:Jx1WSI0jWr7rj9+URd6zrcGlNx0= sha1:Zi380fEGxRg/cnSHCjLGwfUcjBM= Xref: csiph.com comp.std.c:6228 Philipp Klaus Krause writes: > Am 22.06.21 um 20:17 schrieb Keith Thompson: >>> >>> 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? > > I am worried that support for types smaller than int¹ and signed types² > could be controversial. So I'm trying to go for the two types that seem > most useful, most used, and, I hope, least controversial. > > ¹ People might disagree on questions of type and promotion. > ² People might disagree on signed / unsigned for plain types and on > support for 1-bit bit-fields. > > Philipp > > P.S.: Even today, people disagree on some questions on the type of > bit-fields. Even implementations do (e.g. GCC vs. clang). And some say > that the standard is intentionally ambiguous to make the type > essentially implementation-defined. > > P.P.S.: Thanks to everyone for the comments on wording. Are there any implementations that support bit fields of types other than the required ones that *don't* support them for all integer types? I dislike arbitrary restrictions, especially if most implementations won't impose those restrictions anyway. I wouldn't be surprised if all implementations that support non-standard bit field types do so consistently. -- 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 */