On 19.10.2023 21:58, Stefano Stabellini wrote: >>>>>> --- a/xen/include/xen/macros.h >>>>>> +++ b/xen/include/xen/macros.h >>>>>> @@ -8,8 +8,10 @@ >>>>>> #define DIV_ROUND(n, d) (((n) + (d) / 2) / (d)) >>>>>> #define DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d)) >>>>>> >>>>>> -#define MASK_EXTR(v, m) (((v) & (m)) / ((m) & -(m))) >>>>>> -#define MASK_INSR(v, m) (((v) * ((m) & -(m))) & (m)) >>>>> >>>>> a SAF-<n>-safe comment here? >>>>> >>>> >>>> One reason is that now that violations only belonging to tool >>>> configurations >>>> and similar are documented in docs/misra/deviations.rst (committed in >>>> Stefano's >>>> branch for-4.19 [1]). >>> >>> But tool configuration means every analysis tool needs configuring >>> separately. That's why the comment tagging scheme was decided to be >>> preferred, iirc. >>> >>>> Also, there were disagreements on the SAF naming >>>> scheme, and >>>> patches like those would not be accepted at the moment. >>> >>> Well, that needs resolving. The naming there shouldn't lead to patches >>> being accepted that later may need redoing. >>> >>> Jan >> >> While this is true, in this case I'm not willing to deviate with a SAF, given >> that >> some ECLAIR-specific configuration would be needed anyways, given that I'm >> deviating a macro definition, rather than the line where it's actually used >> (and maybe other tools would need >> that as well). > > Did I get it right that the problem with using SAF in this case is that > it wouldn't be sufficient to add a SAF comment on top of the MACRO > definition, but we would need a SAF comment on top of every MACRO > invocation? > > If so, then not just for this MACRO but in general basically we have to > use deviations.rst.
That would be pretty sad. Jan > Luca, do you know what would be the behavior for cppcheck and/or > Coverity? I imagine it will be the same and they would also need a > deviation at every MACRO invocation, not just the definition?
