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: Select all

```
unsigned int tmp = 0;
tmp = (unsigned int)EEPROM_BANK1[1]) + ((unsigned int)EEPROM_BANK1[0] << 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.

*Note: *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.