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) 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
Code: Select all
unsigned int tmp = 0;
tmp = (unsigned int)EEPROM_BANK1) + ((unsigned int)EEPROM_BANK1 << 8u);
DACData.Off = (sshort16)tmp;
With any luck, your compiler will be smart enough to see that bits 16-31 of tmp must always be zero so will generate 16-bit shift and add instructions instead of 32-bit ones, assuming that your target (a) has 16-bit operations and (b) that they are any shorter/quicker than 32-bit ones. If it already generates 32-bit instructions then your aren't losing anything anyway.
You may find a complaint about use of the unsigned int
type (advisory Rule 6.3). It suggests that you use a type that specifies the width explicitly, e.g. uint32_t
. Personally I think this is a situation in which using unsigned int
is justified because it's a portable way to express the smallest unsigned type that it not subject to integer promotion. I would therefore justify not applying Rule 6.3 in this situation. If your project / organisation prefers to comply 100% with every advisory rule then you'll have to use a type that specifies the width of the integer.
I don't have access to a MISRA C:2004 checker so I can't be sure that the above will work but hopefully it, or something like it, will.