Re: [PATCH 0/7] Fix MISRA C 2012 Rule 20.7 violations

[Xenia Ragiadakou <burzalodowa@xxxxxxxxx>]

On 9/2/22 05:07, Stefano Stabellini wrote:
> On Thu, 1 Sep 2022, Bertrand Marquis wrote:
> > Hi Xenia,
> >
> > > On 1 Sep 2022, at 10:27, Xenia Ragiadakou <burzalodowa@xxxxxxxxx> wrote:
> > >
> > >
> > > On 9/1/22 01:35, Stefano Stabellini wrote:
> > > > Patches 1, 4, and 6 are already committed. I plan to commit patches 2, 3
> > > > and 5 in the next couple of days.
> > > > Patch 7 needs further discussions and it is best addressed during the
> > > > next MISRA C sync-up.
> > > I would like to share here, before the next MISRA C sync, my understandings 
> > > that will hopefully resolve a wrong impression of mine, that I may have spread 
> > > around, regarding this rule.
> > > There was a misunderstanding regarding the rule 20.7 from my part and I think 
> > > that Jan is absolutely right that parenthesizing macro parameters used as 
> > > function arguments is not required by the rule.
> > >
> > > The rule 20.7 states "Expressions resulting from the expansion of macro parameters shall be 
> > > enclosed in parentheses" and in the rationale of the rule states "If a macro parameter is 
> > > not being used as an expression then the parentheses are not necessary because no operators are 
> > > involved.".
> > >
> > > Initially, based on the title, my understanding was that it requires for the 
> > > expression resulting from the expansion of the macro to be enclosed in 
> > > parentheses. Then, based on the rule explanation and the examples given,  my 
> > > understanding was that it requires the macro parameters that are used as 
> > > expressions to be enclosed in parentheses.
> > > But, after re-thinking about it, the most probable and what makes more sense, 
> > > is that it require parentheses around the macro parameters that are part of an 
> > > expression and not around those that are used as expressions.
> > >
> > > Therefore, macro parameters being used as function arguments are not required 
> > > to be enclosed in parentheses, because the function arguments are part of an 
> > > expression list, not of an expression (comma is evaluated as separator, not as 
> > > operator).
> > > While, macro parameters used as rhs and lhs expressions of the assignment 
> > > operator are required to be enclosed in parentheses because they are part of an 
> > > assignment expression.
> > >
> > > I verified that the violation reported by cppcheck is not due to missing 
> > > parentheses around the function argument (though still I have not understood 
> > > the origin of the warning). Also, Eclair does not report it.
> > >
> > > Hence, it was a misunderstanding of mine and there is no inconsistency, with 
> > > respect to this rule, in adding parentheses around macro parameters used as rhs 
> > > of assignments. The rule does not require adding parentheses around macro 
> > > parameters used as function arguments and neither cppcheck nor Eclair report 
> > > violation for missing parentheses around macro parameters used as function 
> > > arguments.
> >
> > Thanks a lot for the detailed explanation :-)
> >
> > What you say does make sense and I agree with your analysis here, only protect 
> > when part of an expression and not use as a subsequent parameter (for a 
> > function or an other macro).
> Yeah I also agree with your analysis, and many thanks for
> double-checking the cppcheck and Eclair's reports.
Unfortunately in the specific case that I checked, it was not reported 
because it was actually an argument to a macro, not a function.
Eclair does report as violations of Rule 20.7 the macro parameters that 
are used as function arguments and are not enclosed in parentheses.
So, one tool reports it as violation and the other one not.

The same goes, also, for the case where a macro parameter is used as 
index to an array. Eclair reports it as violation while cppcheck does not.
--
Xenia