Re: Xen reliance on non-standard GCC features

[Jan Beulich <jbeulich@xxxxxxxx>]

On 05.06.2023 07:28, Roberto Bagnara wrote:
> 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.

Sure, it was (I think) always clear that by using extensions we limit
what other compilers Xen may be possible to be built with.

> 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:

I'd like to mention that many "smaller" extensions are either not
mentioned anywhere, or are part of "bigger" extension doc. See e.g. near
the end of 6.20 "Arrays of Variable Length" (gcc 13.1.0 doc), explaining
parameter forward declarations as "another GNU extension". (Sadly that
pattern doesn't have further matches when searching for it.)

> 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.

As per above, tiny extensions like these are, I think, unlikely to be
mentioned anywhere explicitly (or more than in passing). For the last of
the three it may further be that it pre-dates when gcc started to
properly document extensions. Oh, actually - U3 is documented along with
-Wreturn-type.

Uses are generally intentional afaik, but eliminating cases of U2 and U3
would likely be possible with just slight overall impact.

As to U2, it's not clear why you distinguish C99 and C18 mode. Throughout
this summary of yours it would likely have been helpful if an example was
provided for the behavior your describing, when the wording doesn't make
it crystal clear (e.g. no example needed for U1 and U3 above).

As to U1, I'm afraid this statement very early in gcc's section
documenting C extensions simply hasn't been properly updated for newer
versions of the standard: "Some features that are in ISO C99 but not C90
or C++ are also, as extensions, accepted by GCC in C90 mode and in C++."
A somewhat similar statement in the middle of 2.1 "C Language" is
slightly better, thus covering at least the specific case of
_Static_assert.

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

There's not a lot of "extern inline" that we've accumulated so far, I
think. The only ones I'm aware of are sort() and bsearch(), and there
the use is precisely for allowing the compiler to optimize away function
calls.

The documentation of this functionality is that of the gnu_inline
function attribute, afaict. That would be 6.33.1 "Common Function
Attributes" in 13.1.0 doc.

> U5) Enumerator values outside the range of `int'.
> 
> U6) Empty declarations.

For these two I'm surprised you say we have any. The former would need
inspecting, but it's hard to see why the latter shouldn't simply allow
purging. Provided I understand correctly why you mean by "empty", not
the least because ...

> U7) Empty enum definitions.

... here I wonder whether instead you mean forward declaration of enums
(i.e. what the standard allows for structures and unions only).

> U8) Conversion between incompatible pointer types.

Do we have any uses that aren't, by using casts, documenting that the
conversions are deliberate? Otherwise I would expect the compiler to
warn, and hence the build to fail due to -Werror. Then again I'm sure
we have ample uses of casts left which are actually bogus.

> U9) Conversion between function pointers and object pointers.

Uses I'm readily aware of are deliberate. Plus isn't this shorthand
for going through uintptr_t intermediately only anyway?

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

Where did you find such? The only instances I can spot are in
assembler-only constructs, where 'm' really starts the name of an
assembler macro argument. Iirc when the compiler pre-processes
assembly files (identified by being named *.S or use of the option
"-x assembler"), it applies relaxed handling of \ found inside
double quotes.

Then again I find it unlikely that you would have meant those, as
they're inside #ifdef __ASSEMBLY__ (or alike) guarded sections, and
hence shouldn't pop out when analysis tools are run on the tree.

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

I suppose that this list wasn't meant to be complete? The most
prominent example is probably asm().

Jan