On 09/06/22 09:04, Jan Beulich wrote:
On 09.06.2022 03:20, Stefano Stabellini wrote:
Finally, for Rule 13.2, I updated the link to ECLAIR's results. There
are a lot more violations than just 4, but I don't know if they are
valid or false positives.
I've picked just the one case in xen/common/efi/ebmalloc.c to check,
and it says "possibly". That's because evaluation of function call
arguments involves the calling of (in this case two) further
functions. If those functions had side effects (which apparently the
tool can't figure), there would indeed be a problem.
The (Arm based) count of almost 10k violations is clearly a concern.
I don't consider it even remotely reasonable to add 10k comments, no
matter how brief, to cover all the false positives.
Again, the MISRA approach is a preventive one.
If you have reasons you want to write
f(g(), h());
then declare g() and h() as pure (or const, if they are const).
E.g.:
#if COMPILER_SUPPORTS_PURE
#define PURE __attribute__((pure))
#else
#define PURE
#endif
int g(void) PURE;
int h(void) PURE;
It's good documentation, it improves compiler diagnostics,
and it satisfies Rule 13.2.
Kind regards,
Roberto
