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

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



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.

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



 


Rackspace

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