Re:Betrayed by a bitfield (2012)
by kazinator on Sunday July 03, 2016 @01:56PM
(#12026946)
This looks like a compiler problem.
If you turn that bit-field into a plain unsigned int, the problem goes away, right?
If an unsigned int can be accessed all by itself without involving the adjacent lock.
This strongly suggests that the compiler should be using "units" for bit-field allocation which are no larger than unsigned int.
It's odd for for a bit-field derived from, the type unsigned int to cause an access which is wider than unsigned int.
Also, nowhere in the standard does it say that the bit-field "units" can be shared with adjacent non-members. In C99 the wording is, "If enough space remains, a bit-field that immediately follows another bit-field in a structure shall be packed into adjacent bits of the same unit." I.e. unit sharing takes place when a bit-field follows a bit-field. I can find no other text which specifies or permits unit sharing between a non-bit-field and a following bit-field.
If you turn that bit-field into a plain unsigned int, the problem goes away, right?
If an unsigned int can be accessed all by itself without involving the adjacent lock.
This strongly suggests that the compiler should be using "units" for bit-field allocation which are no larger than unsigned int.
It's odd for for a bit-field derived from, the type unsigned int to cause an access which is wider than unsigned int.
Also, nowhere in the standard does it say that the bit-field "units" can be shared with adjacent non-members. In C99 the wording is, "If enough space remains, a bit-field that immediately follows another bit-field in a structure shall be packed into adjacent bits of the same unit." I.e. unit sharing takes place when a bit-field follows a bit-field. I can find no other text which specifies or permits unit sharing between a non-bit-field and a following bit-field.