Xen reliance on non-standard GCC features

[Roberto Bagnara <roberto.bagnara@xxxxxxxxxxx>]

Hi there.

It appears Xen uses lots of GCC features that are outside the C99
standard.  Some of them are documented GNU extensions to the language.
Some of them seem not to be documented, so they do not qualify
as language extensions (at least, not as far as the spirit and letter
of functional-safety standards are concerned).

Language extensions come with two problems:

a) They limit portability.
b) They significantly increase the cost of compiler qualification
   (commercial C compiler validation suites do not cover the extensions,
   and the cost of the extra validation effort will have to be born
   by whomever wants to use Xen for safety-related development).

Said that, maybe the use of certain extensions is intentional, but for
others it may be unintentional.  The purpose of this message is to
distinguish the ones from the others.  In the following, when I mention
the C99 standard, I refer to compiler uses with -std=c99 or -std=gnu99.

Let us start from the (as far as I can tell) undocumented extensions:

U1) Use of _Static_assert in C99 mode.

U2) Empty initialization lists, both in C99 mode (ARM64 and X86_64)
    and C18 mode (only X86_64).

U3) Returning void expressions.

U4) Static functions or variables used in inline functions with external
    linkage.

U5) Enumerator values outside the range of `int'.

U6) Empty declarations.

U7) Empty enum definitions.

U8) Conversion between incompatible pointer types.

U9) Conversion between function pointers and object pointers.

U10) \m escape sequence.
     Is this an undocumented GCC extension or just a typo?

In case you know where these are documented in the GCC manual,
I would appreciate if you could tell me.

Here is a list of extensions that are documented in the GCC manual:

D1) Arithmetic operators on `void *' type:
    See Section "6.24 Arithmetic on void- and Function-Pointers"
    of the GCC manual."

D2) Sizeof and alignof on `void *' type:
    See Section "6.24 Arithmetic on void- and Function-Pointers"
    of the GCC manual."

D3) Use of GNU statement expressions.
    See Section "6.1 Statements and Declarations in Expressions"
    of the GCC manual.

D4) Use of GNU statement expressions from macro expansion.
    See Section "6.1 Statements and Declarations in Expressions"
    of the GCC manual.
    (My advice is to read it fully, as there are implications.)

D5) Record declarations with no members.
    See Section "6.19 Structures with No Members" of the GCC manual."

D6) Structures containing a flexible array member as member of a structure.
    See Section "6.18 Arrays of Length Zero" of the GCC manual.

D7) Structures containing a flexible array member as element of an array.
    See Section "6.18 Arrays of Length Zero" of the GCC manual.

D8) Binary conditional operator.
    See Section "6.8 Conditionals with Omitted Operands" of the GCC manual.

D9) Case labels with upper/lower values.
    See Section "6.30 Case Ranges" of the GCC manual.

D10) Anonymous structure and union fields.
     See Section "6.63 Unnamed Structure and Union Fields" of the GCC manual.

D11) Variadic macros called without any argument for '...'
     See Section "6.21 Macros with a Variable Number of Arguments"
     of the GCC manual.

D12) Forward references to enum definitions.
     See Section "6.49 Incomplete enum Types" of the GCC manual.

Finally, Xen seems to rely on explicitly undefined behavior, namely
C99 UB 58: "A structure or union is defined as containing no named
members (6.7.2.1)." All instances but one occur via macro BUILD_BUG_ON_ZERO,
the remaining instance concerns struct
`cpu_policy::<anonymous union>::<anonymous struct>::<anonymous union>::<anonymous 
struct>'.
Reliance on undefined behavior might be hard to justify.

I look forward to receiving your feedback.
Kind regards,

   Roberto