On Wed, Oct 09, 2019 at 09:15:03AM +0200, Paolo Bonzini wrote: > For stuff like hardware registers, bitfields are probably a bad idea > anyway, so let's only consider the case of space optimization. Except for hardware registers? I actually like bitfields to describe hardware registers. > bool:2 would definitely cause an eyebrow raise, but I don't see why > bool:1 bitfields are a problem. An integer type large enough to store > the values 0 and 1 can be of any size bigger than one bit. Consider: bool foo:1; bool bar:1; Will bar use the second bit of _Bool? Does it have one? (yes it does, but it's still weird). But worse, as used in the parent thread: u8 count:7; bool flag:1; Who says the @flag thing will even be the msb of the initial u8 and not a whole new variable due to change in base type? > bool bitfields preserve the magic behavior where something like this: > > foo->x = y; > > (x is a bool bitfield) would be compiled as > > foo->x = (y != 0); This is confusion; if y is a single bit bitfield, then there is absolutely _NO_ difference between these two expressions. The _only_ thing about _Bool is that it magically casts values to 0,1. Single bit bitfield variables have no choice but to already be in that range. So expressions where it matters are: x = (7&2) // x == 2 vs x = !!(7&2) // x == 1 But it is impossible for int:1 and _Bool to behave differently. > However, in this patch bitfields are unnecessary and they result in > worse code from the compiler. Fully agreed :-)
