[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.