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

Re: [RFC 1/4] x86/ioemul: address MISRA C:2012 Rule 9.3



On Mon, 6 Nov 2023, Nicola Vetrini wrote:
> > > > There's also this functionally equivalent alternative, with or without
> > > > the zeros, which
> > > > doesn't incur in the risk of mistakenly attempting to initialize the
> > > > same element twice,
> > > > while also giving an explicit cue to the reader that all elements are
> > > > truly zero-initialized.
> > > >
> > > >           .matches = {
> > > >               DMI_MATCH(DMI_BIOS_VENDOR, "HP"),
> > > >               DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant DL5"),
> > > > +            {0}, {0}
> > > >           },
> > > 
> > > Adding a dependency on the array actually having 4 elements (while iirc
> > > we have seen already that we could in principle go down to 3). A change
> > > of this number would then require touching all these sites, which is
> > > what we'd like to avoid.
> > 
> > How often the array needs to change though? Looking at the git history
> > it doesn't seem the number of elements ever changed. So I think it is a
> > good tradeoff, and I would go with this type of fix (maybe also at the
> > other locations mechanically too although I haven't looked at them in
> > details).
> 
> Hi, any updates on this? Considering the opinions expressed above, what would
> be the path preferred by the community?

Hi Jan, to bring this discussion to a conclusion, I think we have these
options:

1) fix these violations by adding {}, {}
2) fix these violations by adding [0]=xxx,[1]=xxx
3) deviate these violations by adding /* SAF-safe-xxx */
4) remove the MISRA rule 9.3 from docs/misra/rules.rst

Let's make a decision. My preference is 1) as we only have ~50
violations.



 


Rackspace

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