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