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

PATCH Superseded Dmytro Prokopchuk1 2 participants 9 messages Oct 19 – Nov 10

lore

Share & tools

lore

Dmytro Prokopchuk1

author

2026-10-19 16:54 UTC #0 lore raw

PATCH 1/1 misra: deviate MISRA C Rule 10.1 for boolean operands of arithmetic

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 <[email protected]>

---
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(+)

automation/eclair_analysis/ECLAIR/deviations.ecl +5 -0

index 6cdb10a129..8bfb1a0f89 100644
@@ -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

docs/misra/deviations.rst +6 -0

index 6bcc2adf95..5aeb3ef9a3 100644
@@ -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

docs/misra/rules.rst +2 -0

index a59cf1782e..54b1cefba1 100644
@@ -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.

Signature · 1 line

2.43.0

Jan Beulich

2026-10-26 11:13 UTC #1 lore raw

Quoted 30 lines · 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 <[email protected]>
---
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(+)
automation/eclair_analysis/ECLAIR/deviations.ecl +0 -0
index 6cdb10a129..8bfb1a0f89 100644

automation/eclair_analysis/ECLAIR/deviations.ecl still non-negative." · line 341

Quoted 7 lines

automation/eclair_analysis/ECLAIR/deviations.ecl +4 -0

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

docs/misra/deviations.rst Deviations related to MISRA C:2012 Rules: · line 354

Quoted 11 lines

docs/misra/deviations.rst +5 -0

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

docs/misra/rules.rst maintainers if you want to suggest a change. · line 391

Quoted 8 lines

docs/misra/rules.rst +2 -0

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

Dmytro Prokopchuk

author

2026-11-02 10:20 UTC #2 lore raw

Quoted 34 lines · Jan Beulich

Quoted 33 lines · 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 <[email protected]>
---
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(+)
automation/eclair_analysis/ECLAIR/deviations.ecl +0 -0
index 6cdb10a129..8bfb1a0f89 100644
@@ -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
 

Quoted 6 lines

automation/eclair_analysis/ECLAIR/deviations.ecl still non-negative." · line 341
Quoted 4 lines
automation/eclair_analysis/ECLAIR/deviations.ecl +4 -0
+-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).

Quoted 15 lines

docs/misra/deviations.rst Deviations related to MISRA C:2012 Rules: · line 354

Quoted 12 lines

docs/misra/deviations.rst +5 -0

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

Quoted 11 lines

docs/misra/rules.rst maintainers if you want to suggest a change. · line 391
Quoted 8 lines
docs/misra/rules.rst +2 -0
@@ -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.

Jan Beulich

2026-11-02 10:53 UTC #3 lore raw

Quoted 15 lines · Dmytro Prokopchuk

Quoted 7 lines · Jan Beulich
Quoted 6 lines · On 19.10.2026 18:54, Dmytro Prokopchuk1 wrote:
automation/eclair_analysis/ECLAIR/deviations.ecl +0 -0
@@ -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
 
Quoted 6 lines
automation/eclair_analysis/ECLAIR/deviations.ecl still non-negative." · line 341
Quoted 4 lines
automation/eclair_analysis/ECLAIR/deviations.ecl +4 -0
+-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 ...

Quoted 3 lines

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

Dmytro Prokopchuk

author

2026-11-02 14:43 UTC #4 lore raw

Quoted 20 lines · Jan Beulich

Quoted 15 lines · Dmytro Prokopchuk
Quoted 7 lines · Jan Beulich
Quoted 6 lines · On 19.10.2026 18:54, Dmytro Prokopchuk1 wrote:
automation/eclair_analysis/ECLAIR/deviations.ecl +0 -0
@@ -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
 
Quoted 6 lines
automation/eclair_analysis/ECLAIR/deviations.ecl still non-negative." · line 341
Quoted 4 lines
automation/eclair_analysis/ECLAIR/deviations.ecl +4 -0
+-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 ...
Quoted 3 lines
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).

Quoted 6 lines

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?

Quoted 2 lines

Jan

Jan Beulich

2026-11-02 15:46 UTC #5 lore raw

Quoted 30 lines · Dmytro Prokopchuk

Quoted 20 lines · Jan Beulich
Quoted 15 lines · Dmytro Prokopchuk
Quoted 7 lines · Jan Beulich
Quoted 6 lines · On 19.10.2026 18:54, Dmytro Prokopchuk1 wrote:
automation/eclair_analysis/ECLAIR/deviations.ecl +0 -0
@@ -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
 
Quoted 6 lines
automation/eclair_analysis/ECLAIR/deviations.ecl still non-negative." · line 341
Quoted 4 lines
automation/eclair_analysis/ECLAIR/deviations.ecl +4 -0
+-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 ...
Quoted 3 lines
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).
Quoted 6 lines
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.

Quoted 8 lines

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

Dmytro Prokopchuk

author

2026-11-04 13:28 UTC #6 lore raw

Quoted 43 lines · Jan Beulich

Quoted 30 lines · Dmytro Prokopchuk
Quoted 20 lines · Jan Beulich
Quoted 15 lines · Dmytro Prokopchuk
Quoted 7 lines · Jan Beulich
Quoted 6 lines · On 19.10.2026 18:54, Dmytro Prokopchuk1 wrote:
automation/eclair_analysis/ECLAIR/deviations.ecl +0 -0
@@ -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
 
Quoted 6 lines
automation/eclair_analysis/ECLAIR/deviations.ecl still non-negative." · line 341
Quoted 4 lines
automation/eclair_analysis/ECLAIR/deviations.ecl +4 -0
+-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 ...
Quoted 3 lines
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).
Quoted 6 lines
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.
Quoted 8 lines
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 >>.

Quoted 7 lines

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.

Jan Beulich

2026-11-04 13:31 UTC #7 lore raw

Quoted 54 lines · Dmytro Prokopchuk

Quoted 40 lines · Jan Beulich
Quoted 30 lines · Dmytro Prokopchuk
Quoted 20 lines · Jan Beulich
Quoted 15 lines · Dmytro Prokopchuk
Quoted 7 lines · Jan Beulich
Quoted 6 lines · On 19.10.2026 18:54, Dmytro Prokopchuk1 wrote:
automation/eclair_analysis/ECLAIR/deviations.ecl +0 -0
@@ -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
 
Quoted 6 lines
automation/eclair_analysis/ECLAIR/deviations.ecl still non-negative." · line 341
Quoted 4 lines
automation/eclair_analysis/ECLAIR/deviations.ecl +4 -0
+-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 ...
Quoted 3 lines
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).
Quoted 6 lines
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.
Quoted 8 lines
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).
Quoted 8 lines
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.
I agree these uses would be equally well defined.

Quoted 8 lines

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.

I do think the wider form is what we want to go with, yet at the same time it's not just me to take that decision.

Jan

Dmytro Prokopchuk

author

2026-11-10 08:39 UTC #8 lore raw

Quoted 60 lines · Jan Beulich

Quoted 59 lines · Dmytro Prokopchuk
Quoted 40 lines · Jan Beulich
Quoted 30 lines · Dmytro Prokopchuk
Quoted 20 lines · Jan Beulich
Quoted 15 lines · Dmytro Prokopchuk
Quoted 7 lines · Jan Beulich
Quoted 6 lines · On 19.10.2026 18:54, Dmytro Prokopchuk1 wrote:
automation/eclair_analysis/ECLAIR/deviations.ecl +0 -0
@@ -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
 
Quoted 6 lines
automation/eclair_analysis/ECLAIR/deviations.ecl still non-negative." · line 341
Quoted 4 lines
automation/eclair_analysis/ECLAIR/deviations.ecl +4 -0
+-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 ...
Quoted 3 lines
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).
Quoted 6 lines
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.
Quoted 8 lines
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).
Quoted 8 lines
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.
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.

Quoted 8 lines

Quoted 3 lines
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.
I do think the wider form is what we want to go with, yet at the same time it's not just me to take that decision.
Jan

Ack.
I'll post v2.

BR, Dmytro.