Re: [XEN PATCH][for-next v2 6/8] x86/mce: Move MC_NCLASSES into the enum mctelem_class

[Jan Beulich <jbeulich@xxxxxxxx>]

On 17.10.2023 10:12, Nicola Vetrini wrote:
> On 17/10/2023 09:02, Jan Beulich wrote:
>> On 16.10.2023 18:05, Nicola Vetrini wrote:
>>> On 16/10/2023 17:45, Jan Beulich wrote:
>>>> On 12.10.2023 17:28, Nicola Vetrini wrote:
>>>>> The definition of MC_NCLASSES contained a violation of MISRA C:2012
>>>>> Rule 10.1, therefore by moving it as an enumeration constant 
>>>>> resolves
>>>>> the
>>>>> violation and makes it more resilient to possible additions to that
>>>>> enum.
>>>>
>>>> And using an enumerator as array dimension specifier is okay for 
>>>> Misra?
>>>> That would be odd when elsewhere named enums are treated specially.
>>>
>>> Yes, the array subscript operator is one of the few places where an 
>>> enum
>>> can be used as
>>> an operand (also because negative values wouldn't compile), as opposed
>>> to mixing them
>>> with ordinary integers.
>>
>> When saying "odd" I didn't even think of negative values. May I 
>> therefore
>> ask for the reasoning of why this specific case is deemed non-risky? To
>> me there looks to be a fair risk of creating undersized arrays, leading
>> to out-of-bounds accesses.
> 
> Two reasons: MC_NCLASSES is the last value of the enum, and a pattern 
> I've spot in various
> other places in Xen, so I assumed it was a fairly common pattern for the 
> community.
> The other reason is that since the value of an enum constant can be 
> derived statically, there
> is little risk of it being the wrong value, because no arithmetic is 
> done on it in its use
> as an array's size (and besides, the enum changed the last time ~15 
> years ago, so I think
> it's unlikely to change much in the near future).

You focus on the specific instance, yet my question was on the general
principle.

Jan