Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Storage needed when there are bit-field members Date: Sun, 28 Jun 2026 09:42:15 -0700 Organization: A noiseless patient Spider Lines: 54 Message-ID: <86v7b27h20.fsf_-_@linuxsc.com> References: <10v7b32$2u85v$1@dont-email.me> <10vjsg2$259m3$3@dont-email.me> <10vkk65$l8v$1@reader1.panix.com> <10vlvie$2ne3j$2@dont-email.me> <10vmh2e$b44$1@reader1.panix.com> <86h5mv8umk.fsf@linuxsc.com> <111amdq$1at39$1@dont-email.me> <111b35d$1duuq$1@kst.eternal-september.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Sun, 28 Jun 2026 16:42:19 +0000 (UTC) Injection-Info: dont-email.me; logging-data="3938968"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19FZgQGabA5RAxhEUBL8WQFTBxBBwQGIb8="; posting-host="3a99bb5a17ff81ccf0b256ea0a03a57b" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:c9WGg+sDpK9UFOhhmqqi8GIu0nY= sha1:KFHg44qjs3DoRh4ChpvVLXhYuUY= sha256:soybeZtdUYtVp1Lu+T8wnCTdNhj0tfIGBFjhsXRREXY= sha1:NqW6qDBA/qYgTGzErFqGy6aZ9Cc= sha256:tRy07gGBSJrB6GVywgd8TK9RGkrlG/Yz6LMlWvG2IsY= sha1:6kooV4JYacq+A4Ovx1/UrefglS8= Xref: csiph.com comp.lang.c:400273 Keith Thompson writes: [...] > uint32_t x; > says precisely that x is 32 bits, unsigned, with no padding bits. Actually it says a little bit more, but never mind that. > But > uint32_t bf : 1; > is meaningfully different from > unsigned bf : 1; > only because in most implementations (and ABIs), the underlying type > of a bit field affects the layout of the entire structure. I would say this differently. The two member declarations shown might be meaningfully different, depending on the implementation: they >can< be different, but they don't have to be, and indeed on many implementations they are exactly the same. > I accept that this is the case, but it's never made any sense to me, > and there's no hint of it in the C standard. I think saying there is not even a hint is an overstatement. The C standard says that an implementation "may allocate any addressable storage unit large enough to hold a bit-field." It shouldn't be a surprise that how much storage is allocated depends on the type of the bit-field member. For example, a bit-field of type 'unsigned' might very well choose a larger storage unit than what is chosen for a bit-field of type '_Bool'. It seems obvious that the type of a bit-field might affect what size and layout is chosen. > For example, if I write: > uint64_t bf : 1; > then the containing struct is typically at least 64 bits, even > though those other 63 bits aren't part of the bit field and other > members can be allocated within them. > > It would make a lot more sense *to me* if an N-bit bit field were > simply N bits. Two problems with that. One, it seems to be in conflict with what the C standard says about 0-width bit-fields. Two, the C standard explicitly allows allocating bit-fields using a high-to-low order or a low-to-high order (implementation-defined choice). Presumably this freedom is given to accommodate both big- and little-endian platforms. The idea that an N-bit bit-field should simply be N bits doesn't work in big-endian environments. It seems better to allow little-endian implementations to choose a size that matches what a big-endian implementation would use, rather than insisting that they be different.