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

[Nicola Vetrini <nicola.vetrini@bugseng.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.
> 
> I am happy either way but I wanted to provide that as an option.
> 
> 

It's also worth considering the magnitude of required SAF comments when 
making this choice.
In this case, from a cursory glance at the present violations, it seems 
that there are maybe a
handful of switches inside macros, so they shouldn't be problematic to 
deal with.

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)