Will a invalid value assigned to an enum can cause memory corruption?

Question

I have got a enum

typedef enum State_t {
    NOT_READY = 0,
    NULL = 1,
    READY = 2,
    NOT_READY = 3,
    WORK_READY = 4
} State_t;

If we assign

State_t state_t = -1;

Would it cause any issue?

You need to cast the integer first. No memory issue, it's OK and 100% safe that way. But the resulting value might be a large one, because the underlying type for the enum can be unsigned. — Cheers and hth. - Alf, Sep 19 '15 at 14:47
@πάνταῥεῖ: Since this is a common technique I rather doubt it would be UB. — Cheers and hth. - Alf, Sep 19 '15 at 14:48
I am getting memory access violation error. Unfortunately I am working with an API and I don't have access to the source code, so can't debug it. I am just trying to assess which line of code in the API is caving in. — Rizwan Hasan, Sep 19 '15 at 14:56
@RizwanHasan One of the points of using an enum is to limit a range of possible values to a range of valid values. Unless the API documentation states that using -1 is acceptable, it most likely isn't. A very likely scenario is that the code in question uses the enum's value as an index somewhere. — molbdnilo, Sep 19 '15 at 15:09
@πάνταῥεῖ [it's not UB.](https://stackoverflow.com/questions/24683156/enumeration-object-set-to-a-value-not-equal-to-any-of-its-respective-enumeration) — The Paramagnetic Croissant, Sep 19 '15 at 15:53
`NOT_READY` appears twice, and the name `NULL` will inevitably cause trouble in real code as it conflicts with the homonymous null-pointer macro (even if you don't use it yourself, as you should not in modern C++, some header might pull it in). And the initialisation should not compile without a cast anyway. So this is not your real code. — Christian Hackl, Sep 19 '15 at 15:59

score 3 · Answer 1 · answered Sep 19 '15 at 14:48

3

It will not cause "memory corruption." It may however cause a surprising value to exist in the variable, either -1 if the enum type is signed or some huge value if it is unsigned. Enums are generally signed by default, but this is not guaranteed by the language standards.

answered Sep 19 '15 at 14:48

John Zwinck

239,568
38
324
436

signed or unsigned isn't that depend on implementation. Or is it signed by default ? – ameyCU Sep 19 '15 at 14:52
The language standard does not promise a signed enum unless you specify negative values when declaring it (or you use a signed type with `enum class` in C++11). It is implementation dependent, but most implementations I have seen happen to use signed unless a declared value would not fit (e.g. you have `UINT_MAX` in there and no negative values). – John Zwinck Sep 19 '15 at 14:56

score 1 · Answer 2 · answered Sep 19 '15 at 17:10

The title of the question asks a very different question than does the body of the question. The title asks whether the assignment will cause memory corruption. The body asks whether it could cause any issue.

These are two very different questions. As several of the other answers have correctly noted, this assignment will not result in memory corruption. It can however cause "issues", particularly in a switch statement. The compiler is free to assume that the only values that an object of some enumerated type can take on are those listed in the enumeration.

#include <iostream>

enum abc {
    a = 1,
    b = 2,
    c = 3
};

char to_letter (abc l)
{
    switch (l) {
        case a :
            return 'a';
        case b :
            return 'b';
        case c :
            return 'c';
        default :
            return 'z';
    }
}

int main ()
{
    lower_case_letter x;
    x = static_cast<abc>(-1);
    std::cout << to_letter(x) << '\n';
}

In every implementation I've worked, this will print 'z'. That, however, relies on unspecified behavior. (That's not as bad as relying on undefined behavior, but it is a close second.) The compiler is free to assume that the only possible values that the argument to to_letter takes on are the three values explicitly specified in the enum.

I don't believe the compiler can make that assumption. Every enumerated type is compatible with some integer type and thus can hold any value of that type. Do you have a reference which suggests that not to be the case? — rici, Sep 20 '15 at 03:31

score 0 · Answer 3 · answered Sep 19 '15 at 16:20

0

No memory corruption. If it is unsigned one, you may see a very big value stored in variable.

answered Sep 19 '15 at 16:20

Austin

1,709
20
40

Will a invalid value assigned to an enum can cause memory corruption?

3 Answers3