3 ms·
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,
by mwkaufma 7mo ago
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?
- kazinator 7mo agoI 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 uint32_t uf2 : 8; bf.uf2 = 255; and use a shift of 24: u2 = bf.uf2 << 24; the behavior observed on GCC will not change if we edit the declaration of the member to unsigned char: unsigned char uf2; I.e. an unsigned bitfield that is 8 bits wide is basically like unsigned char and promotes that way. From that the reasoning follows for other widths.