Re: [PATCH v1] misra: add deviation for rules 21.1 and 21.2

[Jan Beulich <jbeulich@xxxxxxxx>]

On 25.04.2025 17:53, Nicola Vetrini wrote:
> On 2025-04-25 10:07, Jan Beulich wrote:
>> On 24.04.2025 23:45, Stefano Stabellini wrote:
>>> On Thu, 24 Apr 2025, Jan Beulich wrote:
>>>> On 23.04.2025 19:54, victorm.lira@xxxxxxx wrote:
>>>>> From: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
>>>>>
>>>>> MISRA C Rules 21.1 ("#define and #undef shall not be used on a
>>>>> reserved identifier or reserved macro name") and R21.2 ("A reserved
>>>>> identifier or reserved macro name shall not be declared") violations
>>>>> are not problematic for Xen, as it does not use the C or POSIX
>>>>> libraries.
>>>>>
>>>>> Xen uses -fno-builtin and -nostdinc to ensure this, but there are 
>>>>> still
>>>>> __builtin_* functions from the compiler that are available so
>>>>> a deviation is formulated for all identifiers not starting with
>>>>> "__builtin_".
>>>>>
>>>>> The missing text of a deviation for Rule 21.2 is added to
>>>>> docs/misra/deviations.rst.
>>>>>
>>>>> To avoid regressions, tag both rules as clean and add them to the
>>>>> monitored set.
>>>>>
>>>>> Signed-off-by: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
>>>>> Signed-off-by: Federico Serafini <federico.serafini@xxxxxxxxxxx>
>>>>> Signed-off-by: Victor Lira <victorm.lira@xxxxxxx>
>>>>
>>>> While the rule is in the library section, ...
>>>>
>>>>> --- a/docs/misra/deviations.rst
>>>>> +++ b/docs/misra/deviations.rst
>>>>> @@ -587,7 +587,31 @@ Deviations related to MISRA C:2012 Rules:
>>>>>         construct is deviated only in Translation Units that present 
>>>>> a violation
>>>>>         of the Rule due to uses of this macro.
>>>>>       - Tagged as `deliberate` for ECLAIR.
>>>>> -
>>>>> +
>>>>> +   * - R21.1
>>>>> +     - Rule 21.1 reports identifiers reserved for the C and POSIX 
>>>>> standard
>>>>> +       libraries. Xen does not use such libraries and all 
>>>>> translation units
>>>>> +       are compiled with option '-nostdinc', therefore there is no 
>>>>> reason to
>>>>> +       avoid to use `#define` or `#undef` on such identifiers 
>>>>> except for those
>>>>> +       beginning with `__builtin_` for which compilers may perform 
>>>>> (wrong)
>>>>> +       optimizations.
>>>>> +     - Tagged as `safe` for ECLAIR.
>>>>
>>>> ... I'd like to ask that it be explicitly clarified here that it's 
>>>> solely
>>>> the library (and not e.g. the compiler itself) that are of concern 
>>>> here.
>>>
>>> The language can be clarified:
>>>
>>> - Rule 21.1 reports identifiers reserved for the C and POSIX standard
>>>   libraries. Xen does not use such libraries and all translation units
>>>   are compiled with option '-nostdinc', therefore there is no reason 
>>> to
>>>   avoid to use `#define` or `#undef` on C and POSIX standard libraries
>>>   identifiers except for those beginning with `__builtin_` for which
>>>   compilers may perform (wrong) optimizations.
>>
>> Which makes it more apparent that there is a gap: What about e.g. 
>> __x86_64__?
>> That falls within what the rules cover, is not a C or POSIX standard 
>> library
>> identifier, yet very clearly must not be fiddled with. Whereas the text
>> above deviates it.
> 
> that is true, even if unlikely: one approach could be to avoid deviating 
> predefined macros for all CUs as -nostdinc and -fno-builtins should take 
> care of the rest; this kind of deviation is not currently possible in 
> ECLAIR, but it might be in the future.

Is this perhaps because by "all pre-defined macros" you really mean _just_
those, and not the entire reserved (for that purpose) sub-namespace? Imo
we should not go by what a particular compiler may pre-define (we may even
overlook something if we did it this way).

Jan

> I think this could be 
> accomplished also via some gcc trickery on each CU, though I'm not sure 
> how valued that is for Xen.
>