MISRA2004-12_7-3 - Underlying type of LHS operand

[jbrookley]

I'm currently using Parasoft's C++ Test program and it's flagging the last line of the code below and I'm not seeing the error . . . "The error I'm getting is Underlying type of LHS operand of bitwise operator is signed type." Below is the code:

[code]typedef signed short sshort16;

struct DACStruct
{
sshort16 Off;
};

struct DACStruct DACData;

DACData.Off = (sshort16)(EEPROM_BANK1[1]) + (((sshort16)(EEPROM_BANK1[0]))

[Steve Montgomery]

The LHS operand of the

[jbrookley]

Thanks for the suggestion! At least now I know what it's referring to. I actually tried this two different ways and both seemed to violate 10.5 (The result of [a

[Steve Montgomery]

I'd made assumption, for no good reason, that your int size was 16 bits in which case Rule 10.5 wouldn't have been a problem because the LHS operand (ushort16)(EEPROM_BANK1[0]) would not be promoted.

I think you can avoid the second cast by ensuring that you do the operation using the unsigned int type instead of in ushort16, e.g.

[code]unsigned int tmp = 0;
tmp = (unsigned int)EEPROM_BANK1[1]) + ((unsigned int)EEPROM_BANK1[0]

[jbrookley]

Steve,

I'm looking at the code and I don't see how this code could work as you're trying to left shift a byte by 8 bits and store it into a variable that is only 8 bits. If both EEPROM banks are 0xFF, the final result comes to be 0x00FF, which makes sense as the top byte is basically shifting itself nowhere. Was the code meant to show the following?

[code]unsigned short tmp = 0; /* changed here from int to short */
tmp = (unsigned int)EEPROM_BANK1[1]) + ((unsigned int)EEPROM_BANK1[0]

[Steve Montgomery]

I was assuming that unsigned int is at least 16 bits wide. The C standard doesn't permit it to be any narrower than this (see C99 Sections 6.2.5 and 5.2.4.2.1).

So, the left shift and the addition are both performed in a type that is at least 16 bits wide. It it guaranteed that the results of both operations will fit in those 16 (or more) bits. It's also guaranteed that all bits numbered 16 and higher will be 0 so your compiler can select 16-bit instructions if it's able to and if doing so would be beneficial. That means you shouldn't lose out on efficiency and will gain portability.

[misra-c]

This matter appears to be resolved, so we have nothing more to add.