The behavior of value-initializing an enum

Question

First, I want to say, according to cppreference.com, it is somewhat impossible to value-initialize an enum.

According to http://en.cppreference.com/w/cpp/language/value_initialization, value-initializing an enum actually performs zero-initialization. It then follows that, according to http://en.cppreference.com/w/cpp/language/zero_initialization, the effect of zero-initializing an enum is:

If T is a scalar type, the object's initial value is the integral constant zero implicitly converted to T.

However, an integral constant zero is not implicitly convertible to an enum. Ultimately, an enum cannot be value-initialized. This sounds weird, and value-initializing an enum does work on VC, GCC, and clang. So, what does the standard say about this?

Second, according to http://en.cppreference.com/w/cpp/language/static_cast:

Integer, floating-point, or enumeration type can be converted to any complete enumeration type (the result is unspecified (until C++17) undefined behavior (since C++17) if the value of expression, converted to the enumeration's underlying type, is not one of the target enumeration values)

So, does this imply that value-initializing an enum (if it works at all) may actually lead to undefined behavior if the target enum does not have an enumerator equal to 0?

Answer 1

The answer to this was given in the comments. My attempt of explaining the entire standardese behind it is given below.

To zero-initialize an object or reference of type T means:

• if T is a scalar type (3.9), the object is initialized to the value obtained by converting the integer literal 0 (zero) to T;

(Enumerations are scalar types; §3.9/9) So as the conversion is not said to be implicit, we're not looking in §4, but §5.2.9;

The result of the expression static_cast<T>(v) is the result of converting the expression v to type T.

§5.2.9/10 then defines how integral values are converted to enumeration types.

A value of integral or enumeration type can be explicitly converted to an enumeration type. The value is unchanged if the original value is within the range of the enumeration values (7.2). Otherwise, the resulting value is unspecified (and might not be in that range).

It must be shown that zero is in the range of enumeration values for all enumerations.
The next five quotes are taken from §7.2/8:

For an enumeration whose underlying type is fixed, the values of the enumeration are the values of the underlying type.

Since all permitted underlying types include zero in their range of values*, this automatically gives the desired result. Now, for enumerations without fixed underlying types,

Otherwise, 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:

I.e. we have to show that b_min is always less than or equal to zero, and b_max is always greater or equal to zero.

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 2M − 1, where M is a non-negative integer.

|e _max| is non-negative, and the maximum of two numbers is at least as large as both numbers are. Hence max(|e _min| − K, |e _max|) is non-negative as well, and b_max must be greater or equal to that number - so our first requirement is met.

b _min is zero if e_min is non-negative and −(b_max + K) otherwise.

b_min is clearly either zero or negative: b_max is non-negative as shown above, and K is non-negative (0 or 1), hence the additive inverse of their sum is non-positive. Our second requirement is met. Finally,

If the enumerator-list is empty, the values of the enumeration are as if the enumeration had a single enumerator with value 0.

This leads to the above result by setting e_min = e_max = 0.

---

• This reduces to the claim "All integral types have zero in their range of values", which is left to prove for the reader.

Answer 2

1: This can be undestood like so:

enum class SomeEnum : int { V1 = 0, V2 = 1, V3 = 2 }; 
SomeEnum a = 0; // compile error
SomeEnum b = SomeEnum.V1; // OK

This is basic protection from undefined behavior!

2: Yes and Yes :)

SomeEnum c = static_cast<SomeEnum>(1); // = SomeEnum.V2
SomeEnum d = static_cast<SomeEnum>(5); // undefined behavior

static_cast is dangerous by definition, it shoud only be used to support serrialization or old c interfaces!