Which enum values are undefined behavior in C++14, and why? - c++

Question

A footnote in the standard implies that any enum expression value is defined behavior; why does Clang's undefined behavior sanitizer flag out-of-range values?
Consider the following program:
enum A {B = 3, C = 7};
int main() {
A d = static_cast<A>(8);
return d + B;
}
The output under the undefined behavior sanitizer is:
$ clang++-5.0 -fsanitize=undefined -ggdb3 enum.cc && ./a.out
enum.cc:5:10: runtime error: load of value 8, which is not a valid value for type 'A'
Note that the error is not on the static_cast, but on the addition. This is also true when an A is created (but not initialized) and then an int with value 8 is memcpyied into the A - the ubsan error is on the addition, not the initial load.
IIUC, ubsan in newer clangs does flag an error on the static_cast in C++17 mode. I don't know if that mode also finds an error in the memcpy. In any case, this question is focused on C++14.
The reported error comports with the following parts of the standard:
dcl.enum:
For an enumeration whose underlying type is fixed, the values of the enumeration are the values of the underlying type. Otherwise, the values of the enumeration are the values representable by a hypothetical integer types with minimal range exponent M such that all enumerators can be represented. The width of the smallest bit-field large enough to hold all the values of the enumeration type is M. It is possible to define an enumeration that has values not defined by any of its enumerators. If the enumerator-list is empty, the values of the enumeration are as if the enumeration had a single enumerator with value 0.100
So the values of the enumeration A are 0 through 7, inclusive, and the "range exponent" M is 3. Evaluating an expression of type A with value 8 is undefined behavior according to expr.pre:
If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable values for its type, the behavior is undefined.
But there is one hiccup: that footnote from dcl.enum reads:
This set of values is used to define promotion and conversion semantics for the enumeration type. It does not preclude an expression of enumeration type from having a value that falls outside this range. [emphasis mine]
Question: Why is an expression with value 8 and type A undefined behavior if "[dcl.enum] does not preclude an expression of enumeration type from having a value that falls outside this range"?

Answer 1

Clang flags the use of static_cast on a value that is out of range. The behavior is undefined, if the integral value is not within the range of the enumeration.
C++ standard 5.2.9 Static cast [expr.static.cast] paragraph 7
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 enumeration value is unspecified / undefined (since C++17).

Answer 2

Note the phrasing of footnote 100: "[This set of values] does not preclude [stuff]." This is not an endorsement of the "stuff" as valid; it merely emphasizes that this section does not declare the stuff invalid. It is in fact a neutral statement that should bring to mind the fallacy of the excluded middle. As far as this section goes, values outside the values of the enumeration are neither approved nor disapproved. This section defines which values are outside the values of the enumeration, but it is left to other sections (like expr.pre) to decide the validity of using such values.
You can think of this footnote as a warning to those writing compilers: do not assume! An expression of enumeration type need not have a value within the enumeration's set of values. Such a case must compile correctly unless another section classifies that case as undefined behavior.
For a better understanding of what exactly clang is complaining about, try the following code:
enum A {B = 3, C = 7};
int main() {
// Set a variable of type A to a value outside A's set of values.
A d = static_cast<A>(8);
// Try to evaluate an expression of type A with this too-big value.
if ( !static_cast<bool>(static_cast<A>(8)) )
return 2;
// Try again, but this time load the value from d.
if ( !static_cast<bool>(d) ) // Sanitizer flags only this
return 1;
return 0;
}
The sanitizer does not complain about forcing a value of 8 into a variable of type A. It does not complain about evaluating an expression of type A that happens to have the value 8 (the first if). It does, though, complain when the value of 8 comes from (is loaded from) a variable of type A.

Answer 3

I'm not real familiar with Clang's compiler since I am accustomed to Visual Studio. I am currently using Visual Studio 2017. I was able to compile and run your code with language flag set to both c++14 and c++17 in both x86 and x64 debug builds. Instead of returning the addition in your example:
return d + B;
I had decided to output them to the console:
std::cout << (d + B);
and in all 4 cases my compiler printed out a value of 11.
I'm not sure about GCC either as I haven't tried it with your example, but this is leading me to believe that this is a compiler dependent issue.
I had followed your link and read section 8 in which you had referred to, but what caught my attention from that draft are the details coming from other sections namely 7 and 10.
Section 7 states:
For an enumeration whose underlying type is not fixed, the underlying type is an integral type that can represent all the enumerator values defined in the enumeration. If no integral type can represent all the enumerator values, the enumeration is ill-formed. It is implementation-defined which integral type is used as the underlying type except that the underlying type shall not be larger than int unless the value of an enumerator cannot fit in an int or unsigned int. If the enumerator-list is empty, the underlying type is as if the enumeration had a single enumerator with value 0.
But it is this sentence or clause that caught my attention:
It is implementation-defined which integral type is used as the underlying type except that the underlying type shall not be larger than int unless the value of an enumerator cannot fit in an int or unsigned int.
Section 10 states:
The value of an enumerator or an object of an unscoped enumeration type is converted to an integer by integral promotion. [ Example:
enum color { red, yellow, green=20, blue };
color col = red;
color* cp = &col;
if (*cp == blue) // ...
makes color a type describing various colors, and then declares col as an object of that type, and cp as a pointer to an object of that type. The possible values of an object of type color are red, yellow, green, blue; these values can be converted to the integral values 0, 1, 20, and 21. Since enumerations are distinct types, objects of type color can be assigned only values of type color.
color c = 1; // error: type mismatch, no conversion from int to color
int i = yellow; // OK: yellow converted to integral value 1, integral promotion
Note that this implicit enum to int conversion is not provided for a scoped enumeration:
enum class Col { red, yellow, green };
int x = Col::red; // error: no Col to int conversion
Col y = Col::red;
if (y) { } // error: no Col to bool conversion
— end example ]
It is these two lines that caught my attention:
color c = 1; // error: type mismatch, no conversion from int to color
int i = yellow; // OK: yellow converted to integral value 1, integral promotion
So let's look back at your example:
enum A {B = 3, C = 7};
int main() {
A d = static_cast<A>(8);
return d + B;
}
Here A is a complete type, B & C are the enumerators which are evaluated to a constant expression of integral type by promotion and are set to the values of 3 and 7 accordingly. This covers the declaration of enum A{...};
Inside of main() you now declare an instance or an object of A called d since A is a complete type. Then you assign d a value of 8 which is a constant expression or constant literal through the mechanism of static_cast. I'm not 100% sure if every compiler performs static_cast in the same exact manner or not; I'm not sure if this is compiler dependent.
So d is an object of type A, but since the value 8 is not in the list of enumerations, I believe this falls under the clause of implementation defined. This should then promote d to an integral type.
Then on your final statement where you return d+B.
Let's say that d was promoted to integral type with a value of 8, then you are adding the enumerated value of B which is 3 to 8, and therefore you should get an output of 11 in which I have in all 4 of my test cases on visual studio.
Now as for your compiler with Clang I can not say, but as far as I can tell this doesn't seem to produce any errors or undefined behavior at least according to Visual Studio. Then again because this code appears to be implementation defined, I think this relies heavily on your particular compiler and its version as well as the language version you are compiling it under.
I can not say that this will completely answer your question, but maybe it will shed some insight into the underlining workings of the compilers according to the documentations of the drafts & standards.
-Edit-
I decided to run this through my debugger and I put a break point on this line:
A d = static_cast<A>(8);
Then I stepped through to execute this line of code and looked at the value in the debugger. Here in Visual Studio, d does have a value of 8. However under its type it is listed as A and not int. So I do not know if this is a promoting it to int or not, or if it might happen to be a compiler optimization, something under the hood such as asm that is treating d as an int or unsigned int, etc.; but Visual Studio is allowing me to assign an integral value through a static_cast to an enumerated type. However, if I remove the static_cast it does fail to compile stating you can not assign a type int to a type A.
This leads me to believe that my original statement above is actually incorrect or only partially correct. The compiler is not fully "promoting" it to an integer type on assignment as d still remains an instance of A unless if it is doing so under the hood that I am unaware of.
I have not yet checked to see the asm of this code to see what assembly instructions are being generated by Visual Studio... therefore I am not currently able to make a full assessment at this point. Now, later on if I have more available time; I may look into it to see what asm lines are being generated by my compiler to see the underlying actions the compiler is taking.