Title
Undefined behavior with enumerator value overflow
Status
cd2
Section
9.7.1 [dcl.enum]
Submitter
Daniel Kr├╝gler

Created on 2009-04-07.00:00:00 last changed 144 months ago

Messages

Date: 2009-10-15.00:00:00

[Voted into WP at October, 2009 meeting.]

Date: 2009-07-15.00:00:00

Proposed resolution (July, 2009):

Change 9.7.1 [dcl.enum] paragraph 5, bullet 3 as follows:

  • Otherwise the type of the initializing value is the same as the type of the initializing value of the preceding enumerator unless the incremented value is not representable in that type, in which case the type is an unspecified integral type suficient to contain the incremented value. If no such type exists, the program is ill-formed.
Date: 2009-04-07.00:00:00

The type of an enumerator that has no initializing value in an enumeration whose underlying type is not fixed is given by the third bullet of 9.7.1 [dcl.enum] paragraph 5:

the type of the initializing value is the same as the type of the initializing value of the preceding enumerator unless the incremented value is not representable in that type, in which case the type is an unspecified integral type sufficient to contain the incremented value.

This does not address the case in which there is no such type, meaning that it is apparently undefined behavior. Other cases in which an enumeration value is unrepresentable are made ill-formed (see the preceding paragraph for an enumeration with a fixed underlying type and the following paragraph for the case in which the minimum and maximum values cannot be represented by a single type). It would be better if this case were ill-formed as well, instead of causing undefined behavior.

History
Date User Action Args
2010-03-29 00:00:00adminsetstatus: dr -> cd2
2009-11-08 00:00:00adminsetmessages: + msg2451
2009-11-08 00:00:00adminsetstatus: ready -> dr
2009-08-03 00:00:00adminsetmessages: + msg2156
2009-08-03 00:00:00adminsetstatus: open -> ready
2009-04-07 00:00:00admincreate