Re: Xen reliance on non-standard GCC features

[Jan Beulich <jbeulich@xxxxxxxx>]

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

The C99 text mentions escape sequences the first time in phase 5, which
means string literals inside preprocessor conditionals which evaluated
to false were already removed. For tokenization all that should matter
is escaped double quotes (when determining the end of a string literal),
escaped single quotes (when processing character constants), and
escaped backslashes.

> 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__ */

As long as these comments are unambiguous, I for one strictly prefer
the shorter form.

Jan