| Message ID | 6622a2ec7079f86b73ae420e1e840d3d35ffb3a0.1697123806.git.nicola.vetrini@bugseng.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | address violations of MISRA C:2012 Rule 10.1 | expand |
On Thu, 12 Oct 2023, 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. > > Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
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. Jan > --- a/xen/arch/x86/cpu/mcheck/mctelem.c > +++ b/xen/arch/x86/cpu/mcheck/mctelem.c > @@ -64,8 +64,6 @@ struct mctelem_ent { > > #define MC_NENT (MC_URGENT_NENT + MC_NONURGENT_NENT) > > -#define MC_NCLASSES (MC_NONURGENT + 1) > - > #define COOKIE2MCTE(c) ((struct mctelem_ent *)(c)) > #define MCTE2COOKIE(tep) ((mctelem_cookie_t)(tep)) > > diff --git a/xen/arch/x86/cpu/mcheck/mctelem.h b/xen/arch/x86/cpu/mcheck/mctelem.h > index d4eba53ae0e5..21b251847bc0 100644 > --- a/xen/arch/x86/cpu/mcheck/mctelem.h > +++ b/xen/arch/x86/cpu/mcheck/mctelem.h > @@ -55,8 +55,9 @@ > typedef struct mctelem_cookie *mctelem_cookie_t; > > typedef enum mctelem_class { > - MC_URGENT, > - MC_NONURGENT > + MC_URGENT, > + MC_NONURGENT, > + MC_NCLASSES > } mctelem_class_t; > > extern void mctelem_init(unsigned int);
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. > > Jan > 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.
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. Jan
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. > > Jan 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).
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
On 17/10/2023 10:26, Jan Beulich wrote: > 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 A couple of reasons why this is allowed: - associating values to set of symbols is typical and makes sense in some contexts - out-of-bounds operations on arrays are dealt with by a host of other guidelines (Series 18, mainly) - this rule is about which kinds of operands makes sense to use with certain operators. It was deemed unlikely by MISRA that risky behaviour may arise by using symbolic indices as subscripts, given the rest of the other guidelines and the unspecified and undefined associated with Rule 10.1. It's not impossible that problems will arise, but far less likely than using enums with no restrictions at all (such as those caused by an enum of and implementation-defined type used in an arithmetic operation, that could give unexpected results).
On 17.10.2023 11:43, Nicola Vetrini wrote: > On 17/10/2023 10:26, Jan Beulich wrote: >> 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. > > A couple of reasons why this is allowed: > - associating values to set of symbols is typical and makes sense in > some contexts > - out-of-bounds operations on arrays are dealt with by a host of other > guidelines > (Series 18, mainly) > - this rule is about which kinds of operands makes sense to use with > certain operators. > It was deemed unlikely by MISRA that risky behaviour may arise by > using symbolic indices > as subscripts, given the rest of the other guidelines and the > unspecified and undefined > associated with Rule 10.1. It's not impossible that problems will > arise, but far less > likely than using enums with no restrictions at all (such as those > caused by an enum of > and implementation-defined type used in an arithmetic operation, that > could give > unexpected results). Now you appear to focus on uses of arrays, not their definition. Yet even there I wonder: array[idx] is nothing else than *(array + idx). Adding integer types and enums is disallowed. Nothing is said about arithmetic on pointers throughout the description of the type model and its rules. So despite the restriction on integer types, adding enums to pointers is permitted? Jan
On 17/10/2023 11:54, Jan Beulich wrote: > On 17.10.2023 11:43, Nicola Vetrini wrote: >> On 17/10/2023 10:26, Jan Beulich wrote: >>> 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. >> >> A couple of reasons why this is allowed: >> - associating values to set of symbols is typical and makes sense in >> some contexts >> - out-of-bounds operations on arrays are dealt with by a host of other >> guidelines >> (Series 18, mainly) >> - this rule is about which kinds of operands makes sense to use with >> certain operators. >> It was deemed unlikely by MISRA that risky behaviour may arise by >> using symbolic indices >> as subscripts, given the rest of the other guidelines and the >> unspecified and undefined >> associated with Rule 10.1. It's not impossible that problems will >> arise, but far less >> likely than using enums with no restrictions at all (such as those >> caused by an enum of >> and implementation-defined type used in an arithmetic operation, >> that >> could give >> unexpected results). > > Now you appear to focus on uses of arrays, not their definition. Yet > even > there I wonder: array[idx] is nothing else than *(array + idx). Adding > integer types and enums is disallowed. Nothing is said about arithmetic > on pointers throughout the description of the type model and its rules. > So despite the restriction on integer types, adding enums to pointers > is > permitted? > > Jan It's not disallowed just to add enums to integers, but the operation of addition on (named) enums. The MISRA C coding standard deemed arr[IDX] an appropriate (not to be interpreted as safe, though what is unsafe is inappropriate as a consequence of the essential type model) use of enums.
diff --git a/xen/arch/x86/cpu/mcheck/mctelem.c b/xen/arch/x86/cpu/mcheck/mctelem.c index 329ac20faf96..77a4d1d5ff48 100644 --- a/xen/arch/x86/cpu/mcheck/mctelem.c +++ b/xen/arch/x86/cpu/mcheck/mctelem.c @@ -64,8 +64,6 @@ struct mctelem_ent { #define MC_NENT (MC_URGENT_NENT + MC_NONURGENT_NENT) -#define MC_NCLASSES (MC_NONURGENT + 1) - #define COOKIE2MCTE(c) ((struct mctelem_ent *)(c)) #define MCTE2COOKIE(tep) ((mctelem_cookie_t)(tep)) diff --git a/xen/arch/x86/cpu/mcheck/mctelem.h b/xen/arch/x86/cpu/mcheck/mctelem.h index d4eba53ae0e5..21b251847bc0 100644 --- a/xen/arch/x86/cpu/mcheck/mctelem.h +++ b/xen/arch/x86/cpu/mcheck/mctelem.h @@ -55,8 +55,9 @@ typedef struct mctelem_cookie *mctelem_cookie_t; typedef enum mctelem_class { - MC_URGENT, - MC_NONURGENT + MC_URGENT, + MC_NONURGENT, + MC_NCLASSES } mctelem_class_t; extern void mctelem_init(unsigned int);
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. Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com> --- Note that the use of an enum constant as operand to [ ] and != is allowed by the Rule. --- xen/arch/x86/cpu/mcheck/mctelem.c | 2 -- xen/arch/x86/cpu/mcheck/mctelem.h | 5 +++-- 2 files changed, 3 insertions(+), 4 deletions(-)