• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 54 subscribers
  • Views 1936 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

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

Kieran Devine
Prodigy 150 points


Hello

I would like to find out if the following MISRA warning is being reported correctly, because to me the code doesn't correspond to the warning:

An example of my code is:

typedef enum { enum1,  enum2 }  enumType;

void function (void)                                                                                                                                                                                                                                                                                    {                          

   enumType Variable1;

    Variable1 = enum1;

}

This generates the following MISRA warning:

(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 

The --enum_type in my C/C++ Build Propeties is set to "packed". This warning doesn't seem to be reported when the --enum_type is set to "int".

Can anyone tell me if this is a misreported MISRA warning, or if I am mistaken?

Regards

Kieran

  • 0
    TI__Expert 4540 points

    Kieran,

    You are correct that this is a bug in the compiler. The fix has been implemented and will be available in the 4.8.0 production release. That release is scheduled for mid December. You can track the bug at SDOWP with the bug id SDSCM00037366.

  • 0 in reply to Cody Addison
    Prodigy 150 points

    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?

  • 0 in reply to Kieran Devine
    TI__Expert 4540 points

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

  • 0 in reply to Cody Addison
    Prodigy 150 points

    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.

  • 0 in reply to Kieran Devine
    Prodigy 150 points

    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.

  • 0 in reply to Kieran Devine
    TI__Expert 4540 points

    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.