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

[Roberto Bagnara <roberto.bagnara@xxxxxxxxxxx>]

On 16/06/23 08:53, Jan Beulich wrote:
> On 16.06.2023 01:26, Stefano Stabellini wrote:
> > On Thu, 15 Jun 2023, Roberto Bagnara wrote:
> > I have a few comments below, mostly to clarify the description of some
> > of the less documented GCC extensions, for the purpose of having all
> > community members be able to understand what they can and cannot use.
> What do you mean by "can and cannot use"? Is this document intended to
> forbid the use of any extensions we may not currently use, or we use
> but which aren't enumerated here?
>
> One of the reasons that kept me from replying to this submission is
> that the full purpose of this new doc isn't stated in the description.
My full purpose was to give the community a starting point for the
discussion on the assumptions the project makes on the programming
language and the translation toolchains that are intended to be used
now or in the future.  As far as I know, no documentation is currently
provided on these topics, so I believe the document fills a gap and
I hope it is good enough as a starting point.

> Which in turn leaves open whether certain items actually need to be
> here (see e.g. the libc related remark below).
Because the analyzed build used to included some of the tools, which in turn
relied on libc for program termination.  Once confirmation is given
that the analyzed build is now what is intended, all references to
libc can be removed.

> Another is that it's
> hard to tell how to convince oneself of this being an exhaustive
> enumeration. One extension we use extensively yet iirc is missing here
> is omission of the middle operand of the ternary operator.
Not sure I understand: do you mean something different from the following
entry in the document?

   * - Binary conditional expression
     - ARM64, X86_64
     - See Section "6.8 Conditionals with Omitted Operands" of GCC_MANUAL.


> > > +Reference Documentation
> > > +_______________________
> > > +
> > > +The following documents are referred to in the sequel:
> > > +
> > > +GCC_MANUAL:
> > > +  https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc.pdf
> > > +CPP_MANUAL:
> > > +  https://gcc.gnu.org/onlinedocs/gcc-12.1.0/cpp.pdf
> Why 12.1 when meanwhile there's 12.3 and 13.1?
For no special reason: as I said, my purpose is only to provide
a starting point for discussion and customization of the
assumptions.

> > > +ARM64_ABI_MANUAL:
> > > +  
> > > https://github.com/ARM-software/abi-aa/blob/60a8eb8c55e999d74dac5e368fc9d7e36e38dda4/aapcs64/aapcs64.rst
> > > +X86_64_ABI_MANUAL:
> > > +  
> > > https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/master/raw/x86-64-ABI/abi.pdf?job=build
> > > +ARM64_LIBC_MANUAL:
> > > +  https://www.gnu.org/software/libc/manual/pdf/libc.pdf
> > > +X86_64_LIBC_MANUAL:
> > > +  https://www.gnu.org/software/libc/manual/pdf/libc.pdf
> How is libc relevant to the hypervisor?
See above.

> > > +   * - Empty declaration
> > > +     - ARM64, X86_64
> > > +     - Non-documented GCC extension.
> > For the non-documented GCC extensions, would it be possible to add a
> > very brief example or a couple of words in the "References" sections?
> > Otherwise I think people might not understand what we are talking about.
> >
> > For instance in this case I would say:
> >
> > An empty declaration is a semicolon with nothing before it.
> > Non-documented GCC extension.
> Which then could be confused with empty statements. I think in a document
> like this language needs to be very precise, to avoid ambiguities and
> confusion as much as possible. (Iirc from going over this doc yesterday
> this applies elsewhere as well.)
OK.

> > > +   * - Ill-formed source detected by the parser
> > As we are documenting compiler extensions that we are using, I am a bit
> > confused by the name of this category of compiler extensions, and the
> > reason why they are bundled together. After all, they are all separate
> > compiler extensions? Should each of them have their own row?
> +1
OK.

> > > +
> > > +   * - 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.

> > > +   * - Non-standard type
> > Should we call it "128-bit Integers" ?
> Or better more generally "Extended integer types" (or something along
> these lines, i.e. as these are called in the spec)?
OK, "Extended integer types" is indeed a good summary of item 1 of
C99 Section "J.3.5 Integers", which is
"Any extended integer types that exist in the implementation (6.2.5)."