Re: [PATCH] misra: deviate MISRA C Rule 10.1 for boolean operands of arithmetic

[Dmytro Prokopchuk <dmytro_prokopchuk1@xxxxxxxx>]

On 11/2/26 17:45, Jan Beulich wrote:
> On 02.11.2026 15:43, Dmytro Prokopchuk wrote:
> > On 11/2/26 12:52, Jan Beulich wrote:
> > > On 02.11.2026 11:20, Dmytro Prokopchuk wrote:
> > > > On 10/26/26 13:13, Jan Beulich wrote:
> > > > > On 19.10.2026 18:54, Dmytro Prokopchuk1 wrote:
> > > > > > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> > > > > > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> > > > > > @@ -335,6 +335,11 @@ still non-negative."
> > > > > >     -config=MC3A2.R10.1,etypes+={safe, 
> > > > > > "stmt(operator(logical)||node(conditional_operator||binary_conditional_operator))", 
> > > > > > "dst_type(ebool||boolean)"}
> > > > > >     -doc_end
> > > > > >     
> > > > > > +-doc_begin="The result of relational, equality and logical negation operators has type int and value 0 or 1 (C99 6.5.8p6, 6.5.9p3, 6.5.3.3p5),
> > > > > > +so using it as an operand of an arithmetic operator is well defined and well known 
> > > > > > to all Xen developers."
> > > > > > +-config=MC3A2.R10.1,etypes+={safe, 
> > > > > > "stmt(operator(add||sub||mul||add_assign||sub_assign))", 
> > > > > > "src_type(ebool||boolean)"}
> > > > > > +-doc_end
> > > > > Why the restriction to add/sub/mul? The text ...
> > > > Because this is the pattern found in the Eclair's report, and it can be
> > > > deviated safely (as opposed to unary minus, division and remainder which
> > > > are not included intentionally).
> > > Division and remainder aren't very useful with boolean operands, so can
> > > surely be left out. However, more generally: How does "Eclair's report"
> > > matter here? In deviation wording we want to go from what the Misra spec
> > > says. The spec covers all operators. Hence any special casing we do
> > > wants to be justified. And, right now at least, I see no justification
> > > for restricting the deviation to just add/sub/mul.
> > Agreed, the report shouldn't be the argument.
> > The deviation should cover only the established idioms with a clear
> > meaning, and leave the rule's protection in place elsewhere. With a
> > Boolean operand these idioms are:
> > - + and - (and += / -=): "count it if the condition holds",
> > - * (and *=): "this value if the condition holds, else 0".
> >
> > Other operators have no such idiom (at least, I'm not aware of them).
> The use with * easily extends to <<. With that it's only logical to also
> include >>.
>
> With + and - covered, it feels pretty much natural that relational
> operators also want covering.
>
> Once there, and with division and modulo agreed upon to leave out, there
> isn't that much else left, I think.
>
> Jan
I agree these uses would be equally well defined.

My thought is about deviating them without a need. For these operators 
there is currently nothing in Xen. Without the deviation the rule keeps 
protecting new code: e.g. Boolean operand of << would be reported and 
looked at, rather than silently accepted.
So I'd prefer to keep deviation limited to +, - and * (and assignment 
forms). If you still think the wider scope is preferable, I'll of course 
go with that in v3.
BR, Dmytro.