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

[Jan Beulich <jbeulich@xxxxxxxx>]

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