Re: [PATCH v2] docs/misra: add 14.3

[Jan Beulich <jbeulich@suse.com>]

On 07.09.2023 23:45, Stefano Stabellini wrote:
> On Thu, 7 Sep 2023, Jan Beulich wrote:
>> On 07.09.2023 03:22, Stefano Stabellini wrote:
>>> @@ -385,6 +386,17 @@ maintainers if you want to suggest a change.
>>>       - A loop counter shall not have essentially floating type
>>>       -
>>>  
>>> +   * - `Rule 14.3 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_14_03.c>`_
>>> +     - Required
>>> +     - Controlling expressions shall not be invariant
>>> +     - Due to the extensive usage of IS_ENABLED, sizeof compile-time
>>> +       checks, and other constructs that are detected as errors by MISRA
>>> +       C scanners, managing the configuration of a MISRA C scanner for
>>> +       this rule would be unmanageable. Thus, this rule is adopted with
>>> +       a project-wide deviation on if ?: and switch statements.
>>
>> Do we want to go as far as permitting this uniformly for all switch()? In
>> my earlier reply I had included sizeof() for a reason.
>  
> I agree with you that it would be better to restrict it to only some
> switch uses, rather than all of them.
> 
> But if we are going to restrict the deviation to switch(sizeof()), which
> I think is a good idea and I am in favor, wouldn't it be better to
> handle these cases as individual deviations? E.g. docs/misra/safe.json?
> I am assuming there are only few cases like that and adding it here
> makes the rule more complicated.

Personally I think it wants to be both anyway. For one, anything written
here still needs respective SAF annotations for scanners to be uniformly
aware (dealing with deviations in just the Eclair configuration is imo
dubious). And then my general view is that by stating patterns here we
make clear that we tolerate new instances of such constructs, whereas in
other cases we'd be aiming at no deviations in new code.

Jan