Re: MISRA C meeting tomorrow, was: MOVING COMMUNITY CALL Call for agenda items for 9 June Community Call @ 1500 UTC

[Roberto Bagnara <roberto.bagnara@xxxxxxxxxxx>]

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