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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 8 Sep 2023, Nicola Vetrini wrote:
> 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.

That's what I thought as well and why I suggested to only deal with them
in safe.json. However, it doesn't cost us anything to be extra clear, so
I'll send an updated patch with extra clarity.