Re: Xen reliance on non-standard GCC features

[Roberto Bagnara <roberto.bagnara@xxxxxxxxxxx>]

On 05/06/23 10:58, Andrew Cooper wrote:
> On 05/06/2023 6:28 am, Roberto Bagnara wrote:
> > U10) \m escape sequence.
> >       Is this an undocumented GCC extension or just a typo?
> Where are you seeing this?
>
> The only examples I see are in asm macros, and they're all parameter
> substitutions.
>
> This includes the one in x86's bug.h where it's a parameter substitution
> into an .ascii string literal, not an escaped special character in the
> literal.
The point is that escape sequences must be considered for tokenization,
which happens in translation phase 3, as they are relevant for phase 4,
which is where preprocessing directives are processed and removed.

See C99 Section "5.1.1.2 Translation phases" for the definition of the
phases.  So \m is non-compliant even in areas guarded by

#if defined(__ASSEMBLY__)

and a conforming compiler should flag it.  On this, see footnote 65 to 
6.4.4.4p8,
where the 'm' in '\m' is one of "any other character":

  65) The semantics of these characters were discussed in 5.2.2.
      If any other character follows a backslash, the result is not a token
      and a diagnostic is required. See ‘‘future language directions’’ (6.11.4).

Kind regards,

   Roberto

P.S. Note on passing that the comments on the preprocessing directives
     are a bit misleading due to the use of the exclamation mark
     (IMHO "defined(__ASSEMBLY__)" would be better than "!__ASSEMBLY__"):

#ifndef __ASSEMBLY__

...

#else  /* !__ASSEMBLY__ */

...

#endif /* !__ASSEMBLY__ */