Re: [PATCH] x86/DMI: adjustments to comply with Misra C:2012 Rule 9.3

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

On 2023-11-30 13:03, Andrew Cooper wrote:
> On 30/11/2023 12:00 pm, Nicola Vetrini wrote:
> > On 2023-11-30 08:55, Jan Beulich wrote:
> > > The rule demands that all array elements be initialized (or dedicated
> > > initializers be used). Introduce a small set of macros to allow doing 
> > > so
> > > without unduly affecting use sites (in particular in terms of how 
> > > many
> > > elements .matches[] actually has; right now there's no use of
> > > DMI_MATCH4(), so we could even consider reducing the array size to 
> > > 3).
> > > Note that DMI_MATCH() needs adjustment because of the comma included 
> > > in
> > > its expansion, which - due to being unparenthesized - would otherwise
> > > cause macro arguments in the "further replacement" step to be wrong.
> > >
> > > Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> > > ---
> > > Of course a question is how many of these DMI table entries are in 
> > > fact
> > > no longer applicable (e.g. because of naming 32-bit-only systems).
> > > Subsequently the table in dmi_scan.c itself may want cleaning up as
> > > well, yet I guess the question of stale entries is even more relevant
> > > there.
> > >
> > > An alternative to using the compound literal approach might be to go
> > > along the lines of
> > >
> > > #define DMI_MATCH4(m1, m2, m3, m4) .matches = { [0] = m1, [1] = m2,
> > > [2] = m3, [3] = m4 }
> > >
> > > I've chosen the other approach mainly because of being slightly 
> > > shorter.
> > From a MISRA perspective this resolves all but one violation: the
> > initialization of static array
> >
> > ns16550_com[2] = { { 0 } };
> >
> > in drivers/char/ns16550.c. This is a case where the explicit
> > initializer looks unnecessary.
>
> Yeah.  That should just be ={}; which ought to resolve the violation?
>
> ~Andrew
Yes

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