This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 119a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2025-12-20
[Moved to DR at October 2002 meeting.]
According to 9.8.1 [dcl.enum] paragraph 5,the underlying type of an enum is an unspecified integral type,which could potentially beunsigned int. The promotionrules in 7.3.7 [conv.prom] paragraph 2saythat such an enumeration value used in an expression will be promotedtounsigned int. This means that a conformingimplementation could give the valuefalse for thefollowing code:
enum { zero }; -1 < zero; // might be falseThis is counterintuitive. Perhaps the description of the underlyingtype of an enumeration should say that an unsigned underlying typecan be used only if the values of the enumerators cannot berepresented in the corresponding signed type. This approach wouldbe consistent with the treatment of integral promotion ofbitfields (7.3.7 [conv.prom] paragraph 3).On a related note,9.8.1 [dcl.enum] paragraph 5says,
the underlying type shall not be larger thanint unlessthe value of an enumerator cannot fit in anint orunsigned int.
This specification does not allow for an enumeration like
enum { a = -1, b = UINT_MAX };Since each enumerator can fit in anintorunsigned int, the underlying type is required to beno larger thanint, even though there is no such type thatcan represent all the enumerators.
Proposed resolution (04/01; obsolete, see below):
Change 9.8.1 [dcl.enum] paragraph 5 as follows:
It is implementation-defined which integral type is used asthe underlying type for an enumeration except that theunderlying type shall not be larger thanint unlessthe value of an enumerator cannot fit in anintorunsigned intneitherint norunsigned int can represent all the enumerator values.Furthermore, the underlying type shall not be an unsignedtype if the corresponding signed type can represent all theenumerator values.
See alsoissue 58.
Notes from 04/01 meeting:
It was noted that 7.3.7 [conv.prom] promotes unsignedtypes smaller thanint to (signed)int. Thesignedness chosen by an implementation for small underlying typesis therefore unobservable, so the last sentence of the proposedresolution above should apply only toint and largertypes. This observation also prompted discussion of analternative approach to resolving the issue, in which thebmin andbmax of the enumerationwould determine the promoted type rather than the underlying type.
Proposed resolution (10/01):
Change 7.3.7 [conv.prom] paragraph 2 from
An rvalue of typewchar_t (6.9.2 [basic.fundamental])or an enumeration type(9.8.1 [dcl.enum]) can be converted to an rvalue ofthe first of the followingtypes that can represent all the values of its underlying type:int,unsigned int,long, orunsigned long.to
An rvalue of typewchar_t (6.9.2 [basic.fundamental])can be converted to an rvalue of the first of the followingtypes that can represent all the values of its underlying type:int,unsigned int,long, orunsigned long.An rvalue of an enumeration type (9.8.1 [dcl.enum])can be converted to an rvalue of the first of the followingtypes that can represent all the values of the enumeration (i.e., thevalues in the rangebmin tobmax asdescribed in 9.8.1 [dcl.enum]):int,unsigned int,long, orunsigned long.