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
