Re: Rule 10.1 violations in perfc_incra and PERFCOUNTER_ARRAY

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

> > > > 3. use an unnamed enum, effectively considering the enumerated values as
> > > > plain
> > > > integers.
> > > >    This does not violate the Rule.
> > >
> > > What do you mean by unname enum?
> >
> > e.g.
> >
> > enum {
> > #include <xen/perfc_defn.h>
> >         NUM_PERFCOUNTERS
> > };
> >
> > instead of
> >
> > enum perfcounter {
> > #include <xen/perfc_defn.h>
> >         NUM_PERFCOUNTERS
> > };
>
> I think this should be easy to do in this case. I gave it a quick try
> and it seems to still build successfully. It could be the best way
> forward for this instance.
>
>
> However in general I am confused why unnamed enum can do comparisons
> between members and named enums cannot. What is the reason? In any 
> case,
> I think we should clarify this detail in the notes section of
> docs/misra/rules.rst, because I don't think it was clear to anyone that
> there is a difference in behavior between named and unnamed enums.
MISRA regards unnamed enums as nothing more than bags of constants that 
may or may not
be related. Such enumeration constants always have a signed essential 
type and also the
anonymous enum type cannot be used, for instance, in the definition of 
new types, as
opposed to a named "enum x {}" that introduces an essential type 
"enum<x>".
I'll send a patch and document the difference.

--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)