On 05/09/11 11:26, Aldy Hernandez wrote:
>
>>> struct
>>> {
>>> unsigned int a : 4;
>>> unsigned char b;
>>> unsigned int c: 6;
>>> } var;
>
>
>> Well, the kernel guys would like to be able to be able to preserve the
>> padding bits too. It's a long long sad story that I won't repeat...
>> And I don't think we should further complicate this stuff with the
>> desire to not clobber padding bits :-) Though be aware the request
>> might come one day....
>
> Woah, let me see if I got this right. If we were to store in VAR.C
> above, the default for this memory model would be NOT to clobber the
> padding bits past <c>? That definitely makes my implementation simpler,
> so I won't complain, but that's just weird.
Just to be clear, it's something I've discussed with the kernel guys and
is completely separate from the C++ memory model. I don't think we
should wrap this into your current work.
Consider if the kernel team wanted to add some information to a
structure without growing the structure. Furthermore, assume that the
structure escapes, say into modules that aren't necessarily going to be
rebuilt, but those modules won't need to ever access this new
information. And assume there happens to be enough padding bits to hold
this auxiliary information.
This has actually occurred and the kernel team wanted to use the padding
bits to hold the auxiliary information and maintain kernel ABI/API
compatibility. Unfortunately, a store to a nearby bitfield can
overwrite the padding, thus if the structure escaped to a module that
still thought the bits were padding, that module would/could clobber
those padding bits, destroying the auxiliary data.
If GCC had a mode where it would preserve the padding bits (when
possible), it'd help the kernel team in these situations.
>
> Arghhh... I was afraid you'd ask for one. It was much easier with the
> test harness on cxx-memory-model. I'll whip one up though...
Given others have (rightly) called me out on it a lot recently, I
figured I'd pass along the love :-)
jeff
