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.vetr...@bugseng.com>
>>>>
>>>> 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
