Title
Signedness of bit fields of enum type
Status
cd1
Section
11.4.10 [class.bit]
Submitter
Steve Adamczyk

Created on 1998-10-13.00:00:00 last changed 162 months ago

Messages

Date: 2006-10-15.00:00:00

[Voted into WP at the October, 2006 meeting.]

Date: 2006-04-15.00:00:00

Proposed resolution (April, 2006):

  1. Replace 9.7.1 [dcl.enum] paragraph 7, deleting the embedded footnote 85, with the following:

    For an enumeration where emin is the smallest enumerator and emax is the largest, the values of the enumeration are the values in the range bmin to bmax, defined as follows: Let K be 1 for a two's complement representation and 0 for a one's complement or sign-magnitude representation. bmax is the smallest value greater than or equal to max(|emin|-K,|emax|) and equal to 2M-1, where M is a non-negative integer. bmin is zero if emin is non-negative and -(bmax+K) otherwise. The size of the smallest bit-field large enough to hold all the values of the enumeration type is max(M,1) if bmin is zero and M+1 otherwise. It is possible to define an enumeration that has values not defined by any of its enumerators.
  2. Add the indicated text to the second sentence of 11.4.10 [class.bit] paragraph 4:

    If the value of an enumerator is stored into a bit-field of the same enumeration type and the number of bits in the bit-field is large enough to hold all the values of that enumeration type (9.7.1 [dcl.enum]), the original enumerator value and the value of the bit-field shall compare equal.
Date: 2005-04-15.00:00:00

Notes from April, 2005 meeting:

Although implementations enjoy a great deal of latitude in handling bit-fields, it was deemed more user-friendly to ensure that the example in paragraph 4 will work by requiring implementations to use an unsigned underlying type if the enumeration type has no negative values. (If the implementation is allowed to choose a signed representation for such bit-fields, the comparison against TRUE will be false.)

In addition, it was observed that there is an apparent circularity between 9.7.1 [dcl.enum] paragraph 7 and 11.4.10 [class.bit] paragraph 4 that should be resolved.

Date: 2005-03-15.00:00:00

Note (March, 2005): Clark Nelson observed that there is variation among implementations on this point.

Date: 2000-02-23.00:00:00

Section 11.4.10 [class.bit] paragraph 4 needs to be more specific about the signedness of bit fields of enum type. How much leeway does an implementation have in choosing the signedness of a bit field? In particular, does the phrase "large enough to hold all the values of the enumeration" mean "the implementation decides on the signedness, and then we see whether all the values will fit in the bit field", or does it require the implementation to make the bit field signed or unsigned if that's what it takes to make it "large enough"?

(See also issue 172.)

History
Date User Action Args
2008-10-05 00:00:00adminsetstatus: wp -> cd1
2007-05-06 00:00:00adminsetstatus: dr -> wp
2006-11-05 00:00:00adminsetmessages: + msg1437
2006-11-05 00:00:00adminsetstatus: ready -> dr
2006-04-22 00:00:00adminsetstatus: review -> ready
2005-10-22 00:00:00adminsetmessages: + msg1243
2005-10-22 00:00:00adminsetstatus: drafting -> review
2005-05-01 00:00:00adminsetmessages: + msg1160
2005-05-01 00:00:00adminsetstatus: open -> drafting
2000-11-18 00:00:00adminsetmessages: + msg429
1998-10-13 00:00:00admincreate