On 09.06.2022 13:17, Roberto Bagnara wrote: > 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.
But such attributes first of all should be correct. They wouldn't be in the case I've looked at (involving two __virt_to_maddr() invocations), as the underlying va_to_par() isn't pure. Still in the normal case the sequence of calls made is irrelevant to the overall result. As to improving compiler diagnostics: It has been my experience that pure and const are largely ignored when used on inline functions. The compiler rather looks at the inline-expanded code to judge. (But it has been a couple of years back that I last checked, so things may have changed since then.) Jan
