1. Patchew
  2. Xen
  3. View series

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

Dmytro Prokopchuk1 posted 1 patch 3 weeks, 1 day ago
There is a newer version of this series
automation/eclair_analysis/ECLAIR/deviations.ecl | 5 +++++
docs/misra/deviations.rst                        | 6 ++++++
docs/misra/rules.rst                             | 2 ++
3 files changed, 13 insertions(+)
[PATCH] misra: deviate MISRA C Rule 10.1 for boolean operands of arithmetic
Posted by Dmytro Prokopchuk1 3 weeks, 1 day ago 
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@epam.com>
---
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
+
 -doc_begin="The macro ISOLATE_LSB encapsulates a well-known pattern to obtain
 a mask where only the lowest bit set in the argument is set, if any, for unsigned
 integers arguments on two's complement architectures
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index 6bcc2adf95..5aeb3ef9a3 100644
--- 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.
+
    * - R10.1
      - Xen only supports architectures where signed integers are representend
        using two's complement and all the Xen developers are aware of this. For
diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index a59cf1782e..54b1cefba1 100644
--- 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 (+ - *)
          - The essential type model allows the constants defined by anonymous
            enums (e.g., enum { A, B, C }) to be used as operands to arithmetic
            operators, as they have a signed essential type.
-- 
2.43.0
Re: [PATCH] misra: deviate MISRA C Rule 10.1 for boolean operands of arithmetic
Posted by Jan Beulich 2 weeks, 2 days ago 
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@epam.com>
> ---
> 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 ...

> --- 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?

Jan
Re: [PATCH] misra: deviate MISRA C Rule 10.1 for boolean operands of arithmetic
Posted by Dmytro Prokopchuk 1 week, 2 days ago 

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@epam.com>
>> ---
>> 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.
Re: [PATCH] misra: deviate MISRA C Rule 10.1 for boolean operands of arithmetic
Posted by Jan Beulich 1 week, 2 days ago 
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.

Jan
Re: [PATCH] misra: deviate MISRA C Rule 10.1 for boolean operands of arithmetic
Posted by Dmytro Prokopchuk 1 week, 1 day ago 

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).

I can put this reasoning into the deviation text in v2. Would that be
acceptable?
> 
> Jan
Re: [PATCH] misra: deviate MISRA C Rule 10.1 for boolean operands of arithmetic
Posted by Jan Beulich 1 week, 1 day ago 
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

Patchew 2.1-devel-ea86937

© 2016 - 2026 Red Hat, Inc.