False-positive messages from MISRA checkers (for assembly code)

[ReinhardKeil]

We have got an report that CMSIS/Include/cmsis_gcc.h violates MISRA C-2012 Rule 9.1 with message:
The value of an object with automatic storage duration shall not be read before it has been set.

The code location refers to functions like this:

__STATIC_FORCEINLINE uint32_t __STREXB(uint8_t value, volatile uint8_t *addr)
{
   uint32_t result;
 
   __ASM volatile ("strexb %0, %2, %1" : "=&r" (result), "=Q" (*addr) : "r" ((uint32_t)value) );
   return(result);
}

The value of the object result is clearly set, therefore I would consider this as false-positive message from the MISRA checker.

I would appreciate if I can get feedback on these two questions:

• Does anyone have experience how to deal with this situation in MISRA checkers?
• Most users may consider the CMSIS Core files as system files and exclude them from checking, but is there a better option?

Thanks
Reinhard

P.S. See also #181

[IngmarPaetzold]

Hi Reinhard,
no such detailed experience.
First, I would not see that as a false-positive. The MISRA checker is only supposed to work on C and cannot know that the ASM statement does actually set variable result. So from the checker's perspective, it is correct.
Concerning error suppression, I have seen code that excludes errors with inline C-comments; this might be viable in a closed production environment with a known MISRA checker, but it's ugly, clutters the code, and, most of all, tempts to hide a real tricky finding. I guess that can be ruled out here (i.e. lint suppressions inside CMSIS code).
Another way was to exclude the finding in the actual project's config files as locally as possible with measures of the actual checker. E.g. for lint:
-efunc( <error-#>, __STREXB ) (see https://support.pclintplus.com/knowledgebase/articles/262827-how-do-i-suppress-a-message-for-a-specific-symbol)
Then at least the project is clean, however, that must be maintained with every update. Don't know whether that works for inline functions, though...

PS: another workaround would be to initialize the object uint32_t result = 0; because we know that this will immediately be changed. The initialized value is never be used in reality, but this should also not be known by the checker for the same reason as above. So it might be satisfied.