[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Xen reliance on non-standard GCC features
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__ */
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |