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

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

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)