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

[Nicola Vetrini <nicola.vetrini@bugseng.com>]

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@suse.com>
>>> ---
>>> 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)