Date: 2006-10-15.00:00:00

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

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.8.1 [dcl.enum] paragraph 7, deleting the embedded footnote 85, with the following:

   For an enumeration where e_min is the smallest enumerator and e_max is the largest, the values of the enumeration are the values in the range b_min to b_max, defined as follows: Let K be 1 for a two's complement representation and 0 for a one's complement or sign-magnitude representation. b_max is the smallest value greater than or equal to max(|e_min|-K,|e_max|) and equal to 2^M-1, where M is a non-negative integer. b_min is zero if e_min is non-negative and -(b_max+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 b_min 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.8.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.8.1 [dcl.enum] paragraph 7 and 11.4.10 [class.bit] paragraph 4 that should be resolved.

Date: 2022-02-18.07:47:23

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.)

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