Re: [PATCH 1/2] automation/eclair_analysis: deviate MISRA C Rule 21.2

[Jan Beulich <jbeulich@xxxxxxxx>]

On 22.06.2024 01:27, Stefano Stabellini wrote:
> On Fri, 21 Jun 2024, Jan Beulich wrote:
>> On 21.06.2024 03:02, Stefano Stabellini wrote:
>>> On Thu, 20 Jun 2024, Jan Beulich wrote:
>>>> On 19.06.2024 19:09, Alessandro Zucchelli wrote:
>>>>> Rule 21.2 reports identifiers reserved for the C and POSIX standard
>>>>> libraries: all xen's translation units are compiled with option
>>>>> -nostdinc, this guarantees that these libraries are not used, therefore
>>>>> a justification is provided for allowing uses of such identifiers in
>>>>> the project.
>>>>> Builtins starting with "__builtin_" still remain available.
>>>>>
>>>>> No functional change.
>>>>>
>>>>> Signed-off-by: Alessandro Zucchelli <alessandro.zucchelli@xxxxxxxxxxx>
>>>>> ---
>>>>>  automation/eclair_analysis/ECLAIR/deviations.ecl | 11 +++++++++++
>>>>>  1 file changed, 11 insertions(+)
>>>>>
>>>>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl 
>>>>> b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>>> index 447c1e6661..9fa9a7f01c 100644
>>>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>>> @@ -487,6 +487,17 @@ leads to a violation of the Rule are deviated."
>>>>>  # Series 21.
>>>>>  #
>>>>>  
>>>>> +-doc_begin="Rules 21.1 and 21.2 report identifiers reserved for the C 
>>>>> and POSIX
>>>>> +standard libraries: if these libraries are not used there is no reason 
>>>>> to avoid such
>>>>> +identifiers. All xen's translation units are compiled with option 
>>>>> -nostdinc,
>>>>> +this guarantees that these libraries are not used. Some compilers could 
>>>>> perform
>>>>> +optimization using built-in functions: this risk is partially addressed 
>>>>> by
>>>>> +using the compilation option -fno-builtin. Builtins starting with 
>>>>> \"__builtin_\"
>>>>> +still remain available."
>>>>
>>>> While the sub-section "Reserved Identifiers" is part of Section 7,
>>>> "Library", close coordination is needed between the library and the
>>>> compiler, which only together form an "implementation". Therefore any
>>>> use of identifiers beginning with two underscores or beginning with an
>>>> underscore and an upper case letter is at risk of colliding not only
>>>> with a particular library implementation (which we don't use), but
>>>> also of such with a particular compiler implementation (which we cannot
>>>> avoid to use). How can we permit use of such potentially problematic
>>>> identifiers?
>>>
>>> Alternative question: is there a way we can check if there is clash of
>>> some sort between a compiler implementation of something and a MACRO or
>>> identifier we have in Xen? An error or a warning from the compiler for
>>> instance? That could be an easy way to prove we are safe.
>>
>> Well. I think it is the default for the compiler to warn when re-#define-
>> ing a previously #define-d (by the compiler or by us) symbol, so on that
>> side we ought to be safe at any given point in time,
> 
> OK, that's good. It seems to me that this explanation should be part of
> the deviation text.
> 
> 
>> yet we're still latently unsafe (as to compilers introducing new
>> pre-defines).
> 
> Sure, but we don't need to be safe in relation to future compiler. Right
> now, we are targeting gcc-12.1.0 as written in
> docs/misra/C-language-toolchain.rst. When we decide to enable a new
> compiler in Xen we can fix/change any specific define as needed. Also
> note the large amount of things written in C-language-toolchain.rst that
> need to be checked and verified for a new compiler to make sure we can
> actually use it safely (we make many assumptions).
> 
> 
>> For built-in declarations, though, there's nothing I'm aware of that
>> would indicate collisions.
> 
> For builtins, Alessandro was suggesting -fno-builtin. One question to
> Alessandro is why would -fno-builtin only "partially" address the
> problem.
> 
> Another question for Jan and also Alessandro: given that builtins
> starting with __builtin_ remain available, any drawbacks in using
> -fno-builtin in a Xen build?

Just to mention it - we're building with -fno-builtin already anyway.
What I'm puzzled by is that it looks like I was under the wrong
impression that we're actually building -ffreestanding (which implies
-fno-builtin).

Jan