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

[Dmytro Prokopchuk <dmytro_prokopchuk1@xxxxxxxx>]

On 10/26/26 13:13, Jan Beulich wrote:
> On 19.10.2026 18:54, Dmytro Prokopchuk1 wrote:
> > MISRA C Rule 10.1 states: "Operands shall not be of an inappropriate
> > essential type".
> >
> > 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 +, -, * and their assignment forms has well-defined
> > semantics.
> >
> > Update ECLAIR configuration to tag such uses as safe.
> >
> > Update deviations.rst and rules.rst accordingly.
> >
> > Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@xxxxxxxx>
> > ---
> > Current patch resolves all ARM Rule 10.1 violations (actually, there were only 
> > two),
> > and resolves around 55 x86 violations.
> >
> > Test CI pipeline:
> > https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/2963748389
> > ---
> >   automation/eclair_analysis/ECLAIR/deviations.ecl | 5 +++++
> >   docs/misra/deviations.rst                        | 6 ++++++
> >   docs/misra/rules.rst                             | 2 ++
> >   3 files changed, 13 insertions(+)
> >
> > diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl 
> > b/automation/eclair_analysis/ECLAIR/deviations.ecl
> > index 6cdb10a129..8bfb1a0f89 100644
> > --- 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).
> > --- a/docs/misra/deviations.rst
> > +++ b/docs/misra/deviations.rst
> > @@ -347,6 +347,12 @@ Deviations related to MISRA C:2012 Rules:
> >          well-known to all Xen developers to be a comparison with 0.
> >        - Tagged as `safe` for ECLAIR.
> >   
> > +   * - R10.1
> > +     - 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 has well-defined semantics.
> > +     - Tagged as `safe` for ECLAIR.
> ... here is less strict, albeit ...
>
> > --- a/docs/misra/rules.rst
> > +++ b/docs/misra/rules.rst
> > @@ -387,6 +387,8 @@ maintainers if you want to suggest a change.
> >              compilers' extensions)
> >            - Implicit conversions to boolean for conditionals (?: if while
> >              for) and logical operators (! || &&)
> > +         - Results of relational, equality and logical negation operators
> > +           (0 or 1) used as operands of arithmetic operators (+ - *)
> ... it's again more strict here, yet at the same time somewhat ambiguous: Are
> all arithmetic operators meant, or merely those named in parentheses?
You're right that these places are inconsistent.
In v2 I can specify the exact operator list (binary +, -, * and +=, -=, 
*=) in all places. Also I think *= need to be added to the ECLAIR 
configuration for consistency with += and -=.
BR, Dmytro.