On 07/06/23 09:39, Jan Beulich wrote:
On 05.06.2023 15:26, Roberto Bagnara wrote:
On 05/06/23 11:28, Jan Beulich wrote:
On 05.06.2023 07:28, Roberto Bagnara wrote:
You are right: here are a few examples for U2:
xen/arch/arm/cpuerrata.c:92.12-92.35:
empty initializer list (ill-formed for the C99 standard, ISO/IEC 9899:1999 Section 6.7.8:
"An empty initialization list." [STD.emptinit]). Tool used is
`/usr/bin/aarch64-linux-gnu-gcc-12'
xen/include/xen/spinlock.h:31.21-31.23: expanded from macro `_LOCK_DEBUG'
xen/include/xen/spinlock.h:143.57-143.67: expanded from macro
`SPIN_LOCK_UNLOCKED'
xen/include/xen/spinlock.h:144.43-144.60: expanded from macro `DEFINE_SPINLOCK'
I'm afraid this is a bad example, as it goes hand-in-hand with using
another extension. I don't think using a non-empty initialization list
is going to work with
union lock_debug { };
Yes, this is C99 undefined behavior 58:
"A structure or union is defined as containing no named members (6.7.2.1)."
Here is another example:
lpae_t pte = {};
whereas we have
typedef union {
uint64_t bits;
lpae_pt_t pt;
lpae_p2m_t p2m;
lpae_walk_t walk;
} lpae_t;
xen/arch/arm/cpuerrata.c:678.5-678.6:
empty initializer list (ill-formed for the C99 standard, ISO/IEC 9899:1999 Section 6.7.8:
"An empty initialization list." [STD.emptinit]). Tool used is
`/usr/bin/aarch64-linux-gnu-gcc-12'
xen/arch/arm/cpufeature.c:33.5-33.6:
empty initializer list (ill-formed for the C99 standard, ISO/IEC 9899:1999 Section 6.7.8:
"An empty initialization list." [STD.emptinit]). Tool used is
`/usr/bin/aarch64-linux-gnu-gcc-12'
Both of these are a common idiom we use: The "sentinel" of an array
of compound type initializer.
Wouldn't it be possible writing such sentinels in a standard-compliant
way, like {0} or similar, instead of {}?
U6) Empty declarations.
Examples:
xen/arch/arm/arm64/lib/find_next_bit.c:57.29:
empty declaration (ill-formed for the C99 standard, ISO/IEC 9899:1999 Section 6.7:
"An empty declaration." [STD.emptdecl]). Tool used is
`/usr/bin/aarch64-linux-gnu-gcc-12'
xen/arch/arm/arm64/lib/find_next_bit.c:103.34:
empty declaration (ill-formed for the C99 standard, ISO/IEC 9899:1999 Section 6.7:
"An empty declaration." [STD.emptdecl]). Tool used is
`/usr/bin/aarch64-linux-gnu-gcc-12'
Looks like these could be taken care of by finally purging our
EXPORT_SYMBOL() stub.
xen/arch/arm/include/asm/vreg.h:143.26:
empty declaration (ill-formed for the C99 standard, ISO/IEC 9899:1999 Section 6.7:
"An empty declaration." [STD.emptdecl]). Tool used is
`/usr/bin/aarch64-linux-gnu-gcc-12'
xen/arch/arm/include/asm/vreg.h:144.26:
empty declaration (ill-formed for the C99 standard, ISO/IEC 9899:1999 Section 6.7:
"An empty declaration." [STD.emptdecl]). Tool used is
`/usr/bin/aarch64-linux-gnu-gcc-12'
I'm having trouble spotting anything suspicious there.
The macro expands to definitions of inline functions
and after the macro invocation there is a ";".
The preprocessed code is then:
static inline void foo() { ... }
;
where the final ";" is an empty declaration not allowed by
the C99 language standard.
Removing the ";" after the macro invocation is a possible solution,
but other possibilities exist if this is strongly unwanted.
We are preparing a new list in RST format, which would go
under docs/misra and constitute a more convenient way for
the community to take note of the used extensions and
contribute to the discussion about their adequacy.