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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 28.04.2025 10:09, Nicola Vetrini wrote:
> 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@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 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,

No, it's not - elsewhere in the tree we may use this to distinguish
architectures. Plus isn't Misra heavily about avoiding developer
confusion? Defining __x86_64__ on Arm code is, imo, a pretty confusing
thing to do.

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

Right. Yet what I'm trying to get to is that we disallow _all_ such
reserved identifiers, not just a subset.

Jan