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

[Jan Beulich <jbeulich@xxxxxxxx>]

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:
>>> +          see the documentation for -Wreturn-type in Section "3.8 Options 
>>> to Request or Suppress Warnings" of GCC_MANUAL.
>>> +       use of GNU statement expression extension from macro expansion:
>>> +          see Section "6.1 Statements and Declarations in Expressions" of 
>>> GCC_MANUAL.
>>> +       invalid application of sizeof to a void type:
>>> +          see Section "6.24 Arithmetic on void- and Function-Pointers" of 
>>> GCC_MANUAL.
>>> +       redeclaration of already-defined enum is a GNU extension:
>>> +          see Section "6.49 Incomplete enum Types" of GCC_MANUAL.
>>> +       static function is used in an inline function with external linkage:
>>> +          non-documented GCC extension.
>>
>> I am not sure if I follow about this one. Did you mean "static is used
>> in an inline function with external linkage" ?
> 
> An inline function with external linkage can be inlined everywhere.
> If that calls a static functions, which is not available everywhere,
> the behavior is not defined.

I guess I could do with an example where this leads to UB. What I'd expect
is that it leads to a compilation error.

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

Jan