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

[Jan Beulich <jbeulich@xxxxxxxx>]

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:
>> 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.

Ah, yes, that is it. I find gcc's title misleading (because there are
far more "conditionals" than just the ternary operator), and hence
when going through you doc I didn't spot this (I'm sorry), and when
then searching for "ternary" and "?:" there were no hits.

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

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.)

Jan