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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 04.11.2026 14:28, Dmytro Prokopchuk wrote:
> 
> 
> 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.
> 
> 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.

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