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

[Nicola Vetrini <nicola.vetrini@bugseng.com>]

On 2025-04-28 08:15, Jan Beulich wrote:
> 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@amd.com wrote:
>>>>>> From: Nicola Vetrini <nicola.vetrini@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.vetrini@bugseng.com>
>>>>>> Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
>>>>>> Signed-off-by: Victor Lira <victorm.lira@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 there is a slight misalignment here: maybe I'm interpreting your 
answer incorrectly. Let me try to restate the proposal: the following 
identifiers are not allowed to be #define'd or #undef'd:
- __builtin_*
- for each CU, all macro identifiers already defined upon preprocessing 
that CU by the compiler invocation for that CU. This set of identifiers 
is always a subset of all the reserved identifiers, but is also 
dependent on the compiler invocation that is used for that CU, (e.g. 
__x86_64__ for an Arm target is usually safe to define, as it's 
typically not a predefined macro introduced by the compiler for that 
invocation, while (re)defining __STDC_VERSION__ or __SIZEOF_INT__ will 
be a violation in any command line I can think of). Note that this is 
not a static set, but is based on what is determined to be predefined at 
the moment of the analysis, so it is not tied to what a particular 
compiler pre-defines.

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

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253