Forcing improper enum values?

Question

I came across some unusual (to me at least...) behavior with C++'s enums. I've tried the following in Visual Studio 2008 and g++ version 4.4.3

#include <iostream>
using namespace std;

enum testEnum
{
    // no zero enum
    one = 1,
    two = 2,
    three = 3
};

int main(int argc, char *argv[])
{
    testEnum e;  // undefined value (may be zero, but thats just luck)
    cout << "Uninitialized enum e = " << e << endl;

    /*
        testEnum e2(0);  // error converting from int to enum
    */

    testEnum e3(testEnum(0)); // forces zero !?!!?!?
    cout << "zero enum e3 = " << e3 << endl;  // prints '0'

    testEnum e4(testEnum(9999)); // forces 9999 ?!?!?!?!
    cout << "9999 enum e4 = " << e4 << endl; // prints '9999'

    return 0;
}

The undefined value for e is as I expected, and I understand why you can't convert from an int to an enum (but you can go the other way).

I'm curious as to how the last two enums (e3 and e4) are allowed to compile and attain any value you want to give them.

Also, I found that this:

testEnum e();

Compiled in both studio and linux, and cout-ing in linux yielded '1' but in studio I got a linker error:

main.obj : error LNK2001: unresolved external symbol "enum testEnum __cdecl e2(void)"

In studio, I could do:

testEnum e = testEnum();

But cout-ing it yielded '0' not '1'

So my main question is how you can ram any value down an enum's throat like e3 and e4 in the above example. And if this is implementation dependent or not.

`testEnum e()` effectively declares a function named `e`, which accepts nothing and returns a `testEnum`. You don't define that function anywhere, of course, hence the error. (Making this a comment since @David has answered the main question among the few you ask) — Eran, Oct 06 '11 at 15:47

score 8 · Answer 1 · answered Oct 06 '11 at 15:42

8

C++ enums are not type-safe. You can, as you say, ram any value down an enums throat. This feature is not implementation dependent, it is enshrined in the standard.

C++11 introduces strongly-typed enumerations which are declared with a different syntax so as not to break your old code with type unsafe enumerations.

answered Oct 06 '11 at 15:42

David Heffernan

601,492
42
1,072
1,490

The values that fit in an enum are unspecified if it's outside of the "range" of the enum though. – Mooing Duck Oct 06 '11 at 16:45
@Mooing True enough. This all makes classic enums pretty hopeless. – David Heffernan Oct 06 '11 at 16:46
1

Scoped enums are still capable of holding out-of-range values if you explicitly cast or default-initialize, as the questioner's example was doing. For example, `enum class foo {A, B, C}; foo bar = foo(16);` is perfectly valid even though `foo` only has values for 0, 1, and 2. – celticminstrel Jul 06 '12 at 04:41

score 8 · Accepted Answer · edited Jan 28 '16 at 16:24

An enum is guaranteed to hold any value in the range between its smallest defined value and its largest, and is unspecified on how it handles numbers outside the range.

§7.2/3
...if not explicitly specified, the underlying type of a scoped enumeration type is int."

§ 7.2/7
...for an enumeration where emin is the smallest enumerator and emax is the largest, the values of the enumeration are the values in the range bmin to bmax, defined as follows: Let K be 1 for a two’s complement representation and 0 for a one’s complement or sign-magnitude representation. bmax is the smallest value greater than or equal to max(|emin| − K, |emax|) and equal to 2M − 1, where M is a non-negative integer. bmin is zero if emin is non-negative and −(bmax + 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 bmin is zero and M + 1 otherwise.

§ 7.2/10
An expression of arithmetic or enumeration type can be converted to an enumeration type explicitly. The value is unchanged if it is in the range of enumeration values of the enumeration type; otherwise the resulting enumeration value is unspecified.

Also note that testEnum e(); declares a function that returns a testEnum This is caused by the Most Vexing Parse. Not sure why GCC decided that equaled one (maybe it got coerced into a pointer->bool somehow?) testEnum e = testEnum(); is a valid statement which default-initializes an testEnum, which for primitives (and apparently enums) means setting them to zero.

Note that this does not mean that enumerations may not take values outside of their defined range; as noted in footnote 96 of N4296:

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.

I should also mention that it isn't particularly complicated to make a typesafe enum in C++03, there's just a few wierd tricks to it. http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Type_Safe_Enum shows one way.

You can also try [Safe Labels in C++](http://www.artima.com/cppsource/safelabels.html) by Fedor Pikus. But this is more for the case where enums do double duty as bitflag field types. — Don Wakefield, Oct 06 '11 at 16:49
@Mooing Duck, can you provide a link to the standard section you cited above? — jCuga, Oct 06 '11 at 17:22
@jCuga: There's a draft of the standard at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf. To get the "real" copy you have to pay ISO money, but I can't find a link for that. — Mooing Duck, Oct 06 '11 at 17:40

score 0 · Answer 3 · answered Oct 06 '11 at 15:47

0

Enum it's just a memory, usually it's implemented as int while the compiler should force you to only assign them the correct values. But no compiler is perfect.. Those cases you presented should not be valid (undef).

answered Oct 06 '11 at 15:47

Roee Gavirel

18,955
12
67
94

Forcing improper enum values?

3 Answers3

Linked