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.l...@amd.com wrote:
>>>>> From: Nicola Vetrini <nicola.vetr...@bugseng.com>
>>>>>
>>>>> 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.vetr...@bugseng.com>
>>>>> Signed-off-by: Federico Serafini <federico.seraf...@bugseng.com>
>>>>> Signed-off-by: Victor Lira <victorm.l...@amd.com>
>>>>
>>>> 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.
>
