Re: [XEN PATCH] docs/misra: document the C dialect and translation toolchain assumptions.

[Roberto Bagnara <roberto.bagnara@xxxxxxxxxxx>]

On 19/06/23 09:54, Jan Beulich wrote:
> On 16.06.2023 17:54, Roberto Bagnara wrote:
> > On 16/06/23 01:26, Stefano Stabellini wrote:
> > > On Thu, 15 Jun 2023, Roberto Bagnara wrote:
> > > > +   * - Unspecified escape sequence is encountered in a character constant or a 
> > > > string literal token
> > > > +     - X86_64
> > > > +     - \\m:
> > > > +          non-documented GCC extension.
> > > Are you saying that we are using \m and \m is not allowed by the C
> > > standard?
> > The C standard does not specify that escape sequence, so what is
> > done with it, in particular by the preprocessor, is not specified.
> Isn't it rather that gcc doesn't follow the spec to the word here?
> As per what preprocessing-token can be, anything that isn't (among
> other things) a string-literal or a character-constants falls under
> "each non-white-space character that cannot be one of the above".
> Hence since "\mode" doesn't form a valid string literal, it would
> need to become (using '' notation for separation purposes, not to
> indicate character constants) '"' '\' 'mode'. Which of course would
> break what subsequently are string literals, as the supposedly
> closing double-quote would now be an opening one. Which in turn is
> presumably the reason why gcc (and probably other compilers as well)
> behaves the way it does.
After a significant amount of work on the matter, we came to the
following conclusions:

1) In this matter, the C Standard is not at all clear regarding
   the conditions upon which it is legitimate placing undefined
   escape sequences in the sources.
2) The GNU C preprocessor manual says nothing in this regard.
3) Experimenting with a lot of compilers, it seems all implementers
   have filled the dots in the same way, that is: during translation
   phase 3, escape sequences are considered for the sole purpose
   of getting preprocessing tokens right; escape sequences, whether
   defined or undefined, are left untouched and passed over to translation
   phase 4.

Summarizing, we are now convinced that what we are facing is one
of the cases (there are many of them), where the C Standard is
not being clear, and not a case of undefined behavior.  Xen use
of \m guarded by __ASSEMBLY__ is thus correct and not problematic.
Indeed, the check for undefined escape sequences can only
be done after preprocessing.  I have asked that ECLAIR
is suitably amended.

Thank you all, and particularly to Jan, for the perseverance.
Kind regards,

   Roberto