Misreported MISRA 10.1 warning on C Code generation tools v4.7.0B2 TMS570

I also have this MISRA warning from working with packed enums:

(MISRA-C:2004 6.1/R) The plain char type shall be used only for the storage and use of character values 

On my build properties, my --abi setting is set to EABI. And according to the "TI ARM Compiler User Guide" page 82 - Having an EABI setting should make all my enums "unsigned char" types and not just plain "char".

Is this another misreported MISRA warning?

Yes, it is a bug. I noticed it while evaluating your example. I have created SDSCM00038580 for the bug.

Since I have been told that both MISRA 10.1 and MISRA 6.1 warnings are both misreported in this example, I have suppressed these MISRA warnings - and once I do that it generates the MISRA 6.2 warning which is:

(MISRA-C:2004 6.2/R) signed and unsigned char type shall be used only for the storage and use of numeric values 

I can't see this being a correct warning either, because surely assigning an enum value to an enum variable in this case,  is the same as assigning a numerical value to an unsigned char.

Perhaps I was a bit vague in my last post. What actually happens is the MISRA 6.2 warning comes up as soon as you try to use the "==" or "!=" .

An new example:

typedef enum { enum1,  enum2 }  enumType;

void function (void)                                                                                                                                                                                                                                                                                    {                          

   enumType Variable1;

    Variable1 = enum1;

    if (enum1 == Variable1)  {

    }

}

I just can't see this MISRA warning being valid either? Can you please verify.

You are correct that this is an invalid warning. What is happening is that your enumerations are packed, so they are represented with a type of char. The enumerators (enum1 and enum2 in this case) are represented with a type of int, as the standard dictates. This is confusing some of the MISRA-C checking code that checks for violations. For the 10.1 and 6.1 bugs, I believe the problem comes from assigning an int (the enumerator) to a char (the enumeration variable). The compiler should ignore the cases where these are enumerations. I have already fixed 10.1, and I think the fix for 6.1 will be similar. The 6.2 bug is probably similar, although it is a little strange that 6.1 explicitly deals with plain char and 6.2 deals with signed/unsigned chars.

I have created SDSCM00038592 to track the bug with the 6.2 rule.