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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 26.10.2023 14:32, Nicola Vetrini wrote:
> On 25/10/2023 09:56, Jan Beulich wrote:
>> On 24.10.2023 22:27, Stefano Stabellini wrote:
>>> On Tue, 24 Oct 2023, Jan Beulich wrote:
>>>> On 24.10.2023 16:31, Nicola Vetrini wrote:
>>>>> Partially explicitly initalized .matches arrays result in violations
>>>>> of Rule 9.3; this is resolved by using designated initializers,
>>>>> which is permitted by the Rule.
>>>>>
>>>>> Mechanical changes.
>>>>>
>>>>> Signed-off-by: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
>>>>
>>>> While not overly bad, I'm still not really seeing the improvement.
>>>> Yet aiui changes induced by Misra are supposed to improve things in
>>>> some direction?
>>>
>>> I think the improvement is clarity, in the sense that the designated
>>> initializers make it clearer that the array may be sparsely 
>>> initialized
>>> and that the remaining elements should be initialized to zero
>>> automatically.
>>
>> That's as clear from the original code, imo.
> 
> 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.

Jan