On Tue, Mar 8, 2022 at 9:15 AM Nadav Amit <namit@xxxxxxxxxx> wrote:
>
> It would be much easier to read. The last time I made such a suggestion,
> Ingo said "I personally like bitfields in theory … [but] older versions of
> GCC did a really poor job of optimizing them.”
Yeah, even not that old versions had serious issues, iirc.
Bitfields can look nice, but they have some _serious_ syntax issues.
In particular, they are nice when you want to *test* one single field
(ie bit in this case), but basically atrociously bad in almost all
other circumstances.
For example, passing a bitfield aggregate as an argument is just
crazy. Oh, you can do it, with syntax like
(struct type) { .field1 = 1, .field3 = 1 }
as the argument but when you say "much easier to read" I laugh in your
face and call your mother a hamster.
And that's ignoring all the issues when you want to combine two
bitfields. You can't do it. There is nothing like the binary "or"
operator. Again, it's easy to modify *one* field, but taking two
bitfields and merging them? Not going to happen.
So no. Bitfields have their place, but they are close to useless as
"flags" type things that get passed around as arguments, unless you
have very very specific and limited use.
Linus
