Re: [PATCH] docs/misra: add R13.2 and R18.2 to rules.rst

[Jan Beulich <jbeulich@xxxxxxxx>]

On 01.08.2024 01:50, Stefano Stabellini wrote:
> On Wed, 31 Jul 2024, Jan Beulich wrote:
>> On 31.07.2024 01:30, Stefano Stabellini wrote:
>>> --- a/docs/misra/rules.rst
>>> +++ b/docs/misra/rules.rst
>>> @@ -462,6 +462,15 @@ maintainers if you want to suggest a change.
>>>       - Initializer lists shall not contain persistent side effects
>>>       -
>>>  
>>> +   * - `Rule 13.2 
>>> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_13_02.c>`_
>>> +     - Required
>>> +     - The value of an expression and its persistent side-effects shall
>>> +       be the same under all permitted evaluation orders
>>> +     - Be aware that the static analysis tool Eclair might report
>>> +       several findings for Rule 13.2 of type "caution". These are
>>> +       instances where Eclair is unable to verify that the code is valid
>>> +       in regard to Rule 13.2. Caution reports are not violations.
>>
>> Which doesn't make clear what our take is towards new code people may
>> submit.
> 
> Good point, see my comment below
> 
> 
>>> @@ -583,6 +592,15 @@ maintainers if you want to suggest a change.
>>>         submitting new patches please try to decrease the number of
>>>         violations when possible.
>>>  
>>> +   * - `Rule 18.2 
>>> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_18_02.c>`_
>>> +     - Required
>>> +     - Subtraction between pointers shall only be applied to pointers
>>> +       that address elements of the same array
>>> +     - Be aware that the static analysis tool Eclair might report
>>> +       several findings for Rule 18.2 of type "caution". These are
>>> +       instances where Eclair is unable to verify that the code is valid
>>> +       in regard to Rule 18.2. Caution reports are not violations.
>>
>> And while the same wording is used here, I think it is pretty clear for
>> this that we'd reject changes where bad subtractions are used. IOW even
>> more so important to clarify the (possibly different) positions on what
>> is going to be added into the code base.
> 
> In both of these cases, we would reject code that doesn't follow R13.2
> and R18.2.

But we shouldn't (unconditionally) do so for for 13.2, should we?

> I'll change it to the following:
> 
> 
> Be aware that the static analysis tool Eclair might report several
> findings for Rule 18.2 of type "caution". These are instances where
> Eclair is unable to verify that the code is valid in regard to Rule
> 18.2. Caution reports are not violations. Regardless, new code is
> expected to follow this rule.

I'm fine with this for 18.2, but not so much for 13.2.

Jan