On Wed, Feb 1, 2012 at 1:25 PM, Boehm, Hans <[email protected]> wrote:
>
> Here are some more interesting ones that illustrate the issues (all
> declarations are non-local, unless stated otherwise):
>
> struct { char a; int b:9; int c:7; char d} x;
>
> Is x.b = 1 allowed to overwrite x.a? C11 says no, essentially requiring two
> byte stores. Gcc currently does so. I'm not sure I understand Linus'
> position here.
So I like the fact that the C11 stance seems very strict. But honestly
I also think it sounds like C11 is actually more strict than I would
necessarily be.
I really do think that bitfields imply "int", both historically and
technically. So I would not see the problem with treating the
bitfields as part of an 'int' and thus overwriting a (and d) when
writing to b. That's how bitfields work! They are fields of an int.
It would be good if it perhaps caused a *warning*, and gave a good way
to avoid it. For example, while I think using any other base type than
'int' is technically an extension of the C bitfield rules (but
whatever, I don't have any specs in front of me), I think a warning
together with alowing the user to rewrite it as
struct { char a; char d; short b:9; short c:7; } x;
would make it clear that now a write to 'b' cannot validly overwrite
'a' or 'd'.
But forcing the compiler to do two (and sometimes three!) byte
accesses sounds excessive.
The reason I think the
int flag:1;
int othervariable;
overwriting of "othervariable" is so *obviously* a bug is exactly that
bitfields are historically about 'int', and no 'long' was there
anywhere, so using a 64-bit access is clearly not sane in any way,
shape or form.
I dunno.
Linus
