Given the following macros in <xen/perfc.h> and
#define perfc_incra(x,y)
\
( (y) <= PERFC_LAST_ ## x - PERFC_ ## x ?
\
++this_cpu(perfcounters)[PERFC_ ## x + (y)] : 0 )
and the following violation
xen/arch/arm/traps.c:1407.5-1407.32:
reference to enum constant `PERFC_hypercalls' has essential type `enum
perfcounter'
and standard type `int'
<preprocessed xen/arch/arm/traps.c>:11606.29-11606.44: preprocessed
tokens
<scratch space>:137.1-137.16: expanded from macro `PERFC_'
xen/include/xen/perfc.h:69.35-69.45: expanded from macro `perfc_incra'
xen/arch/arm/traps.c:1407.5-1407.32:
`+' addition operator expects a number or a character
<preprocessed xen/arch/arm/traps.c>:11606.46: preprocessed tokens
xen/include/xen/perfc.h:69.47: expanded from macro `perfc_incra'
the difference between enumerated values is forbidden by the Rule. In
the coding standard's
interpretation, named enums are unordered list of symbols, which can
only be compared for
equality.
There are a few possible paths forward:
1. use means different from named enums to generate these constants
(such as #define-s or
constants integers);
2. explicitly deviate subtraction of enums, therefore defining an
explicit ordering on
enumerated values;
3. use an unnamed enum, effectively considering the enumerated values as
plain integers.
This does not violate the Rule.
Similarly the sum in
#define PERFCOUNTER_ARRAY( name, descr, size ) \
PERFC_##name, \
PERFC_LAST_##name = PERFC_ ## name + (size) - sizeof(char[2 * !!(size)
- 1]),
causes other analogous violations.
Lastly, this is a concern that manifested only in ARM code, but does not
seem to be related
to ARM-specific files, so there is perhaps some difference in the
configuration of the two
analyzed builds.
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
