C Bit-Field Pitfalls(os2museum.com)
os2museum.com
C Bit-Field Pitfalls
https://www.os2museum.com/wp/bitfield-pitfalls/
9 comments
I just can agree with any interpretation of the article's code that believes programmers should desire silent sign extension when everything about the expression and data types involved is explicitly written to avoid signedness. At the end of the day, programming languages should naturally express intent and not rely on memorization of surprise. Here, I believe that Microsoft correctly employed principle of least surprise, and that ultimately the spec is broken and because of the amount of code in existence just can't be fixed.
I completely agree that C's promotion behavior of unsigned types narrower than int going to int is wonky to a certain extent. However, introducing nonconforming exceptions to that behavior for bit fields doesn't help things. It just breaks correctly written code intended to be portable.
It is much safer to pack/unpack bits manually than trusting bitfields will work as expected.
It's even more confusing than described. C23 6.7.3.1p7 says,
> Each of the comma-separated multisets designates the same type, except that for bit-fields, it is implementation-defined whether the specifier `int` designates the same type as `signed int` or the same type as `unsigned int`.
That means a bit-field member using plain `int` as the underlying type might itself be signed or unsigned, similar to whether plain `char` is signed or unsigned. There's a proposal to address this: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3828.pdf Fortunately, it found that GCC, Clang, MSVC, and ICC all treat `int` bit-fields as `signed int`, and the recommendation is to require this behavior.
That said, I don't think I've ever seen a bit-field deliberately used for signed values; there's some logic to the allowance granted by the standard. And I'm sure there's plenty of real-world code erroneously using `int` bit-fields for unsigned values that just happens to work because of twos-complement representations and the semantics of bitwise operations. But better to limit this kind of flexibility, especially when real-world implementations seem not to have taken the alternative route.
> Each of the comma-separated multisets designates the same type, except that for bit-fields, it is implementation-defined whether the specifier `int` designates the same type as `signed int` or the same type as `unsigned int`.
That means a bit-field member using plain `int` as the underlying type might itself be signed or unsigned, similar to whether plain `char` is signed or unsigned. There's a proposal to address this: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3828.pdf Fortunately, it found that GCC, Clang, MSVC, and ICC all treat `int` bit-fields as `signed int`, and the recommendation is to require this behavior.
That said, I don't think I've ever seen a bit-field deliberately used for signed values; there's some logic to the allowance granted by the standard. And I'm sure there's plenty of real-world code erroneously using `int` bit-fields for unsigned values that just happens to work because of twos-complement representations and the semantics of bitwise operations. But better to limit this kind of flexibility, especially when real-world implementations seem not to have taken the alternative route.
tl;dr standard is unclear if they should respect the signed-ness of the declaration (MSCV), or always promote to int before converting to a receiving type (GCC, Clang).
I suppose you could say MS's choice reflects a commitment to backwards compatibility, whereas GCC/Clang is always chomping at the bit to introduce more aggressive optimizations that signed-integer-undefined-behavior affords?
I suppose you could say MS's choice reflects a commitment to backwards compatibility, whereas GCC/Clang is always chomping at the bit to introduce more aggressive optimizations that signed-integer-undefined-behavior affords?
I would say, GCC's behavior shows commitment to the standard. It's exactly he same logic as the promotion of char/signed char/unsigned char, or int and unsigned int.
That is to say, if we work this example with bitfields that are 8 bits wide, like
That is to say, if we work this example with bitfields that are 8 bits wide, like
uint32_t uf2 : 8;
bf.uf2 = 255;
u2 = bf.uf2 << 24;
unsigned char uf2;
>The troublesome behavior is demonstrated by the lines performing the left shift. We take a 12-bit wide bit-field, shift it left by 20 bits so ...
this is nonsense. I don't know what they expect would happen, but who cares? I wouldn't shift a 12 bit field by more than ±11 bits.
you can shift the "enclosing" word of memory if you want, just put the original definition in a union.
this is nonsense. I don't know what they expect would happen, but who cares? I wouldn't shift a 12 bit field by more than ±11 bits.
you can shift the "enclosing" word of memory if you want, just put the original definition in a union.
For maximal portability, you wouldn't want to shift a 12 bit field by more than 3 bits. Because you know that is narrower than int, but int can be as narrow as 16 bits, which includes a sign bit.
If you assume that int is 32 bits, you can left shift an 12 bit field by 19 bits without hitting the sign bit.
If you assume that int is 32 bits, you can left shift an 12 bit field by 19 bits without hitting the sign bit.
Therefore, convert the values before operating on them: