Title
Integral promotions on bit-fields
Status
nad
Section
7.3.7 [conv.prom]
Submitter
Kiril Avdeiv

Created on 2001-07-24.00:00:00 last changed 280 months ago

Messages

Date: 2001-10-15.00:00:00

Notes from 10/01 meeting:

The standard of course does not dictate what an implementation might do with regard to use of registers or shift instructions in the generated code. The phrase cited means only that a larger bit-field does not undergo integral promotions, and therefore it retains the type with which it was declared (long in the above example). The Core Working Group judged that this was sufficiently clear in the standard.

Note that 11.4.10 [class.bit] paragraph 1 indicates that any bits in excess of the size of the underlying type are padding bits and do not participate in the value representation. Therefore the field1 bit field in the above example is not capable of holding the indicated values, which require more than 32 bits.

Date: 2001-11-09.00:00:00

Paragraph 3 of section 7.3.7 [conv.prom] contains a statement saying that if a bit-field is larger than int or unsigned int, no integral promotions apply to it. This phrase needs further clarification, as it is hardly possible to fugure out what it means. See below.

Assuming a machine with a size of general-purpose register equal 32 bits (where a byte takes up 8 bits) and a C++ implementation where an int is 32 bits and a long is 64 bits. And the following snippet of code:

    struct ExternalInterface {
      long field1:36, field2:28;
    };
    int main() {
      ExternalInterface  myinstance = { 0x100000001L, 0x12,};
      if(myinstance.field1 < 0x100000002L) { //do something }
    }

Does the standard prohibit the implementation from promoting field1's value into two general purpose registers? And imposes a burden of using shift machine instructions to work with the field's value? What else could that phrase mean?

Either alternative is implementation specific, so I don't understand why the phrase "If the bit-field is larger yet, no integral promotions apply to it" made it to the standard.

History
Date User Action Args
2001-11-09 00:00:00adminsetmessages: + msg577
2001-11-09 00:00:00adminsetstatus: open -> nad
2001-07-24 00:00:00admincreate