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

[Roberto Bagnara <roberto.bagnara@xxxxxxxxxxx>]

On 16/06/23 12:03, Jan Beulich wrote:
> On 16.06.2023 09:45, Roberto Bagnara wrote:
> > On 16/06/23 08:53, Jan Beulich wrote:
> > > On 16.06.2023 01:26, Stefano Stabellini 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?
> > > This exists in the __ASSEMBLY__ part of a header, and I had previously
> > > commented on Roberto's diagnosis (possibly derived from Eclair's) here.
> > > As per that I don't think the item should be here, but I'm of course
> > > open to be shown that my understanding of translation phases is wrong.
> > I was not convinced by your explanation but, as I think I have said already,
> > I am not the one to be convinced.  In the specific case, independently
> > from __ASSEMBLY__ or any other considerations, that thing reaches the C
> > preprocessor and, to the best of my knowledge, the C preprocessor documentation
> > does not say how that would be handled.  I have spent a lot of time in the
> > past 10 years on the study of functional-safety standards, and what I
> > am providing is a honest opinion on what I believe is compliant
> > and what is not.  But I may be wrong of course: if you or anyone else feels
> > like they would not have any problems in arguing a different position
> > from mine in front of an assessor, then please go for it, but please
> > do not ask me to go beyond my judgment.
> Well, disagreement on purely a technical matter can usually be resolved,
> unless something is truly unspecified. Since you referred to translation
> phases, and since I pointed out that preprocessing directives are carried
> out before escape sequences are converted to the execution character set
> (which is the point where unknown escape sequences would matter afaict),
> there must be something you view differently in this process. It would be
> helpful if you could point out what this is, possibly leading to me
> recognizing a mistake of mine.
>
> Actually, maybe I figured what you're concerned about: Already at the
> stage of decomposing into preprocessing-token-s there is an issue, as
> e.g. "\mode" doesn't form a valid string-literal. For other, unquoted
> \m I would assume though that the final "each non-white-space character
> that cannot be one of the above" (in the enumeration of what a
> preprocessing-token is) would catch it.
Yes but, more generally, my concern is that the behavior in presence
of unspecified escape sequences is not specified in the C99 standard
and it is not a documented extension according to the documentation
I have examined.  For this reason, I don't think that feature is
usable for safety-related development unless other (potentially
quite expensive) activities are performed (such as prescribing
extra validation activities for the preprocessor).

> Furthermore it is entirely unclear to me what it is that you suggest we
> do instead. It can't reasonably be "name all you assembler macro
> parameters such that they start with a, b, f, n, r, t, or v". Splitting
> headers also wouldn't be very nice - we try to keep related things
> together, after all. It also doesn't look like __stringify(\mode) would
> be okay, as macro expansion shares a translation phase with execution
> of preprocessing directives (so in principle the body of "#if 0" could
> be macro-expanded before being discarded). (Plus I think this would
> result in "\\mode", i.e. also wouldn't work in the first place. But it
> would rule out other possible C macro trickery as well.)
My suggestion is avoiding the use of the C preprocessor
outside its specification.  This includes, among other
possibilities:

a) using a different preprocessor or substitution mechanism;
b) amend the preprocessor specification by, e.g., submitting
   patches with suitable additions for "The C Preprocessor"
   manual of GCC.

In view of that, naming macro parameters so that you never
have an unspecified escape sequence is probably the cheapest
(yet bulletproof) solution.
Kind regards,

   Roberto