How are integer types converted implicitly?

Question

The following code fails on a MISRA check. The concrete error message is:

(MISRA-C:2004 10.1/R) The value of an expression of integer type shall not be implicitly converted to a different underlying type if it is not a conversion to a wider integer type of the same signedness

typedef enum _MyEnum { One, Two } MyEnum;
MyEnum MyVariable;

int foo(void)
{
    int result = 1;

    if (One == MyVariable)  // fails here with MISRA-C:2004 10.1/R
    {
        result = 2;
    }    
    return result;
}

Why is the logical expression converted?
What is converted here?
Why does the code pass the MISRA check, when I swap One and MyVariable?

Edit: The compiler is a TI "MSP430 C/C++ Compiler v4.0.0" with included MISRA rules check.

I already have bad toughts about this MISRA thingy. What you are doing is perfectly fine. — cnicutar, May 14 '12 at 11:38
Does it produce the same error/warning for `if (MyVariable == One) {}` ? — wildplasser, May 14 '12 at 11:58
My compiler does not generate an error but the static analysis tool does, regardless of the order in the `if` expression. — Thomas Matthews, May 14 '12 at 18:56

score 6 · Answer 1 · answered May 24 '12 at 08:24

There is no bug in the MISRA checker, it behaves correctly. You get this error because the C standard is flawed and illogical.

There are two items:

One is an enumeration constant. The standard §6.7.2.2/2 states that this shall be compatible with int, no exceptions.
MyVariable is an enumerated type. The standard §6.7.7.2/4 states that this should be compatible with char, a signed integer type or an unsigned integer type. Which type that applies is implementation-defined behavior.

In your case, the implementation-defined enumerated type appears to be equal to unsigned int.

So the code attempts to implictly convert a variable of signed int to unsigned int, which is a violation of MISRA 2004 10.1.

MISRA-compliant code should be if (One == (MyEnum)MyVariable).

"The standard" is the C standard? If MyVariable is an unsigned int, why does the check succeeds when I swap One and MyVariable? — harper, May 24 '12 at 08:45
@harper Yes, the C standard ISO 9899:2011 (C90 is identical). Well, the swap must be a bug then, it should give you an error no matter which order you use. — Lundin, May 24 '12 at 08:51

score 0 · Answer 2 · answered May 14 '12 at 13:04

0

I would suspect the compiler internally handles enums as unsigned integer, as long there is no negative value within the enum.

answered May 14 '12 at 13:04

dwalter

7,258
1
32
34

score -1 · Accepted Answer · answered May 14 '12 at 11:49

-1

I would suspect a compiler bug. What compiler are you using? This post mentions a compiler bug causing Misra 10.1/R failures when using TI's compiler.

answered May 14 '12 at 11:49

JesperE

63,317
21
138
197

The bug in the link referes to another problem. It's the same MISRA check that fails, but there is it for errornously treatment of an array element. It's not related to a order of enum and variable. – harper May 14 '12 at 12:13
I know. I just mentioned it as an example of a Misra check which failed due to a compiler bug. – JesperE May 14 '12 at 12:23
This is a bug as confirmed by TI. – harper May 15 '12 at 17:25
This is not related to the problem at all. – Lundin May 24 '12 at 08:19
We already agreed on that. What is your point? @harper accepted the answer, which I presume means that my suspicion was correct. – JesperE May 24 '12 at 08:36

How are integer types converted implicitly?

3 Answers3

Linked