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: Thu, 24 Jun 2021 15:16:08 -0700 Organization: None to speak of Lines: 55 Message-ID: <87v962vrh3.fsf@nosuchdomain.example.com> References: <86fsx8bh88.fsf@linuxsc.com> <878s2zw30y.fsf@nosuchdomain.example.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="e76a60976a03f7b22ccc859f0f74fb19"; logging-data="4370"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1832IxFKjvbQdVhs8one5z6" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:jcseywVi4zFvne2jiLox3XIfCyw= sha1:4iszxqjfln8IZLbURXeoD3PVSCE= Xref: csiph.com comp.std.c:6248 David Brown writes: > On 24/06/2021 20:06, Keith Thompson wrote: >> David Brown writes: [...] >>> This would give a very different result from the way compilers implement >>> bitfields today. In particular, consider : >>> >>> sizeof(struct { int8_t a : 1; }); >>> >>> today, that is 1 on compilers that accept any integer type in bit >>> fields. With your proposal, it would be sizeof(int). >> >> How does that follow? The bit field occupies only 1 bit. Why should >> its underlying type affect the size of the structure? > > The current practice is that the size (and alignment) of the struct or > its parts comes from the type used to declare the bit-field - just as > for any other field. As I said below, it would be conceivable for a > compiler to use the programmer's specified type to set the size of the > containing struct or addressable storage unit, while ignoring it for the > type of the field and how it is interpreted when used in an expression. > That would, however, seem arbitrary and counter-intuitive, as well as > being contrary to current practice and (if my interpretation is correct > - but I might be wrong here) to C++ standards. (For simplicity, assume CHAR_BIT==8 and sizeof(int)==4.) I understand that it's existing practice, but it just doesn't make any sense to me. If I define a struct with a bit-field defined as "unsigned int:1", it's a single bit, not a 32-bit unsigned int object. I can pack 8 of them into a single byte. I just don't see why the declared type of a bit field should affect the size of the containing structure when it has no effect on the size of the bit field itself. The structure doesn't *need* those 32 bits of storage. If I add a second unsigned:1 bit-field, the structure doesn't grow by another 32 bits. As N1570 6.7.2.1p10 says, "A bit-field is interpreted as having a signed or unsigned integer type consisting of the specified number of bits.", so the bit-field object isn't really of type unsigned int. For an implementation that doesn't support types other than the required ones, any struct with a 2-bit bit-field would have to be at least 32 bits, while a struct with an unsigned char member could be as small as 8 bits. (Same for a 1-bit bit-field pre-C99.) That seems to me like an arbitrary restriction. I don't use bit-fields much, so maybe I'm missing some reason why this behavior is reasonable and/or useful. [...] -- 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 */