On Tue, 15 Jan 2008, Michael Matz wrote: > Doing arithmetic on small bit-fields on the (larger) promoted type, but > doing them on large bit-fields on the exact width creates an asymmetry.
It's the same as arithmetic on unsigned short actually being done on the promoted type (signed int), while arithmetic on unsigned int involves no promotion. > That asymmetry then reflects into the code generator as ugly special > cases, and actually also in horrible intermediate code (like doing bit > mask operations after all arithmetic). Bit-fields generally give bad code, and masking when loading and storing will generally be needed, and if the result of arithmetic is being stored back in a bit-field of the same width then no further masking should be needed for addition/subtraction/multiplication than that on loads and stores (you can always do those operations on wider types then reduce). > So, if there's opportunity to fix the C standard in the next round by > including language for promotions wider than int, that would be IMO much > better than introducing first-class bit-field types. It would also mirror > current behaviour of many compilers. There have been vague suggestions of introducing requirements-based types (where the programmer would specify bits / representation / range / overflow handling etc.) in future, so anything affecting bit-fields doesn't avoid the possibility of such types as true first-class types (that can be used for toplevel object declarations, not just in structures). -- Joseph S. Myers [EMAIL PROTECTED]
