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

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

[victorm.lira]

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>
---
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Anthony PERARD <anthony.perard@vates.tech>
Cc: Michal Orzel <michal.orzel@amd.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Julien Grall <julien@xen.org>
Cc: Roger Pau Monné <roger.pau@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>
Cc: Federico Serafini <federico.serafini@bugseng.com>
Cc: Bertrand Marquis <bertrand.marquis@arm.com>
---
 .../eclair_analysis/ECLAIR/deviations.ecl     |  9 ++++++-
 .../eclair_analysis/ECLAIR/monitored.ecl      |  2 ++
 automation/eclair_analysis/ECLAIR/tagging.ecl |  2 ++
 docs/misra/deviations.rst                     | 26 ++++++++++++++++++-
 4 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 2c8fb92713..ffa23b53b7 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -639,8 +639,15 @@ in the expansion."
 # Series 21.
 #

+-doc_begin="Xen does not use C and POSIX libraries:
+identifiers reserved by these libraries can be used safely, except for those
+beginning with '__builtin_'."
+-config=MC3A2.R21.1,macros={safe, "!^__builtin_.*$"}
+-config=MC3A2.R21.2,declarations={safe, "!^__builtin_.*$"}
+-doc_end
+
 -doc_begin="or, and and xor are reserved identifiers because they constitute alternate
-spellings for the corresponding operators (they are defined as macros by iso646.h).
+spellings for the corresponding logical operators (as defined in header 'iso646.h').
 However, Xen doesn't use standard library headers, so there is no risk of overlap."
 -config=MC3A2.R21.2,reports+={safe, "any_area(stmt(ref(kind(label)&&^(or|and|xor|not)$)))"}
 -doc_end
diff --git a/automation/eclair_analysis/ECLAIR/monitored.ecl b/automation/eclair_analysis/ECLAIR/monitored.ecl
index 8351996ec8..da229a0d84 100644
--- a/automation/eclair_analysis/ECLAIR/monitored.ecl
+++ b/automation/eclair_analysis/ECLAIR/monitored.ecl
@@ -79,6 +79,8 @@
 -enable=MC3A2.R20.12
 -enable=MC3A2.R20.13
 -enable=MC3A2.R20.14
+-enable=MC3A2.R21.1
+-enable=MC3A2.R21.2
 -enable=MC3A2.R21.3
 -enable=MC3A2.R21.4
 -enable=MC3A2.R21.5
diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/automation/eclair_analysis/ECLAIR/tagging.ecl
index 1d078d8905..3292bf751e 100644
--- a/automation/eclair_analysis/ECLAIR/tagging.ecl
+++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
@@ -88,6 +88,8 @@ MC3A2.R20.11||
 MC3A2.R20.12||
 MC3A2.R20.13||
 MC3A2.R20.14||
+MC3A2.R21.1||
+MC3A2.R21.2||
 MC3A2.R21.3||
 MC3A2.R21.4||
 MC3A2.R21.5||
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index fe0b1e10a2..88328eaa8a 100644
--- 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.
+
+   * - R21.2
+     - Rule 21.2 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 declaring such identifiers except for those beginning with
+       `__builtin_` for which compilers may perform (wrong) optimizations.
+     - Tagged as `safe` for ECLAIR.
+
+   * - R21.2
+     - `or`, `and` and `xor` are reserved identifiers because they constitute
+       alternate spellings for the corresponding logical operators
+       (as defined in Standard Library header `\<iso646.h\>`). Xen does not use
+       Standard library headers, so there is no risk of overlap.
+     - Tagged as `safe` for ECLAIR.
+
    * - R21.9
      - Xen does not use the `bsearch` and `qsort` functions provided by the C
        Standard Library, but provides in source form its own implementation,
--
2.47.0

[PATCH v1] misra: add deviation of Rule 5.5

[victorm.lira]

From: Federico Serafini <federico.serafini@bugseng.com>

MISRA C Rule 5.5 states that:
"Identifiers shall be distinct from macro names".

A common pattern in Xen is to have a function-like macro that acts as a
"wrapper" for the function to be called:
before calling the function, the macro adds additional checks or
increase/decrease the number of parameters depending on the
configuration.

Update ECLAIR configuration and deviations.rst.

Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Signed-off-by: Victor Lira <victorm.lira@amd.com>
---
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Anthony PERARD <anthony.perard@vates.tech>
Cc: Michal Orzel <michal.orzel@amd.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Julien Grall <julien@xen.org>
Cc: Roger Pau Monné <roger.pau@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>
Cc: Federico Serafini <federico.serafini@bugseng.com>
Cc: Bertrand Marquis <bertrand.marquis@arm.com>
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 8 ++++++++
 docs/misra/deviations.rst                        | 8 ++++++++
 2 files changed, 16 insertions(+)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index ffa23b53b7..303b06203a 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -114,6 +114,14 @@ it defines would (in the common case) be already defined. Peer reviewed by the c
 -config=MC3A2.R5.5,reports+={deliberate, "any_area(decl(kind(function))||any_loc(macro(name(memcpy||memset||memmove))))&&any_area(any_loc(file(^xen/common/libelf/libelf-private\\.h$)))"}
 -doc_end

+-doc_begin="Clashes between function-like macros and function names are
+deliberate since a common pattern in Xen is to have a function-like macro
+that acts as a \"wrapper\" for the function to be called:
+before calling the function, the macro adds additional checks or
+increase/decrease the number of parameters depending on the configuration."
+-config=MC3A2.R5.5,reports+={deliberate, "all_area(macro(function_like())||decl(kind(function)))"}
+-doc_end
+
 -doc_begin="The type \"ret_t\" is deliberately defined multiple times,
 depending on the guest."
 -config=MC3A2.R5.6,reports+={deliberate,"any_area(any_loc(text(^.*ret_t.*$)))"}
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index 88328eaa8a..cfdd1a9838 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -130,6 +130,14 @@ Deviations related to MISRA C:2012 Rules:
        memmove.
      - Tagged as `deliberate` for ECLAIR.

+   * - R5.5
+     - Clashes between function-like macros and function names are
+       deliberate since a common pattern in Xen is to have a function-like
+       macro that acts as a "wrapper" for the function to be called:
+       before calling the function, the macro adds additional checks or
+       increase/decrease the number of parameters depending on the configuration.
+     - Tagged as `deliberate` for ECLAIR.
+
    * - R5.6
      - The type ret_t is deliberately defined multiple times depending on the
        type of guest to service.
--
2.47.0

[PATCH v1] misra: add deviation of Rule 10.1 for unary minus

[victorm.lira]

From: Nicola Vetrini <nicola.vetrini@bugseng.com>

MISRA C Rule 10.1 states:
"Operands shall not be of an inappropriate essential type"

The unary minus operator applied to an unsigned quantity has
a semantics (wrap around) that is well-known to all Xen developers.
Thus, this operation is deemed safe.

No functional change.

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>
---
Changes v1:
- add rule title to commit message
---
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Anthony PERARD <anthony.perard@vates.tech>
Cc: Michal Orzel <michal.orzel@amd.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Julien Grall <julien@xen.org>
Cc: Roger Pau Monné <roger.pau@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>
Cc: Federico Serafini <federico.serafini@bugseng.com>
Cc: Bertrand Marquis <bertrand.marquis@arm.com>
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++++++
 docs/misra/deviations.rst                        | 6 ++++++
 2 files changed, 12 insertions(+)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 303b06203a..2cfce850bd 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -347,6 +347,12 @@ constant expressions are required.\""
   "any()"}
 -doc_end

+-doc_begin="Unary minus operations on non-negative integers have a semantics (wrap around) that is well-known to all Xen developers."
+-config=MC3A2.R10.1,etypes+={safe,
+  "stmt(node(unary_operator)&&operator(minus))",
+  "src_expr(definitely_in(0..))"}
+-doc_end
+
 #
 # Series 11
 #
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index cfdd1a9838..c5897e31c5 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -321,6 +321,12 @@ Deviations related to MISRA C:2012 Rules:
        If no bits are set, 0 is returned.
      - Tagged as `safe` for ECLAIR.

+   * - R10.1
+     - Applying the unary minus operator to an unsigned quantity has a
+       semantics (wrap around) that is well-known to all Xen developers.
+       For this reason, the operation is safe.
+     - Tagged as `safe` for ECLAIR.
+
    * - R11.1
      - The conversion from a function pointer to unsigned long or (void \*) does
        not lose any information, provided that the target type has enough bits
--
2.47.0

Re: [PATCH v1] misra: add deviation of Rule 10.1 for unary minus

[Lira, Victor M]

Continuing a discussion from before:

On 4/22/2025 11:51 PM, Jan Beulich wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> On 23.04.2025 01:43, victorm.lira@amd.com wrote:
>> From: Nicola Vetrini <nicola.vetrini@bugseng.com>
>>
>> The unary minus operator applied to an unsigned quantity has
>> a semantics (wrap around) that is well-known to all Xen developers.
>> Thus, this operation is deemed safe.
> Please, as you have it in the other two patches, can the rule title be
> reproduced in such patches? As it stands, without mentioning the doc
> version either, someone finding this later on may be left with a pretty
> wide ambiguity as to what's meant.
OK I'll include the rule title in the commit message.
>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>> @@ -347,6 +347,12 @@ constant expressions are required.\""
>>     "any()"}
>>   -doc_end
>>
>> +-doc_begin="Unary minus operations on non-negative integers have a semantics (wrap around) that is well-known to all Xen developers."
> Why "non-negative"? A variable of type "int" holding a non-negative value is,
> aiui, well within the bounds of the rule here. It's unsigned types where the
> use of unary minus would constitute a violation. You actually say so ...
>> +   * - R10.1
>> +     - Applying the unary minus operator to an unsigned quantity has a
>> +       semantics (wrap around) that is well-known to all Xen developers.
>> +       For this reason, the operation is safe.
>> +     - Tagged as `safe` for ECLAIR.
> ... here, just that this one's getting blurred by using "quantity" when
> "type" is meant. Imo we need to be pretty precise here, using terminology
> that's used by the standard or the Misra rules, and not anything "coming
> close enough" in someone's perception.
OK, I agree it should say unsigned type(s) in both of these.


Victor

Re: [PATCH v1] misra: add deviation of Rule 5.5

[Lira, Victor M]

Continuing a discussion from before:

On 4/22/2025 11:44 PM, Jan Beulich wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> On 23.04.2025 01:43, victorm.lira@amd.com wrote:
>>          memmove.
>>        - Tagged as `deliberate` for ECLAIR.
>>
>> +   * - R5.5
>> +     - Clashes between function-like macros and function names are
>> +       deliberate
> They may or may not be deliberate, depending on context. I don't think it's a
> good move to deviate this more widely than necessary. If I get the expression
> above (in deviations.ecl) right, even
>
> void func1(int);
> void func2(int);
>
> #define func1() func2(0)
> #define func2() func1(0)
>
> would be deviated, which I don't think we want. Especially when, in a less
> contrived scenario, the clash may not easily be visible.
OK, I see the issue for different functions. Does it make sense to say 
it's deliberate when it's the same identifier?

	void func1(int);
	...
	#define func1() func1(0)

Could this be deviated?


Victor

Re: [PATCH v1] misra: add deviation of Rule 5.5

[Stefano Stabellini]

On Wed, 23 Apr 2025, Lira, Victor M wrote:
> Continuing a discussion from before:
> 
> On 4/22/2025 11:44 PM, Jan Beulich wrote:
> > Caution: This message originated from an External Source. Use proper caution
> > when opening attachments, clicking links, or responding.
> > 
> > 
> > On 23.04.2025 01:43, victorm.lira@amd.com wrote:
> > >          memmove.
> > >        - Tagged as `deliberate` for ECLAIR.
> > > 
> > > +   * - R5.5
> > > +     - Clashes between function-like macros and function names are
> > > +       deliberate
> > They may or may not be deliberate, depending on context. I don't think it's
> > a
> > good move to deviate this more widely than necessary. If I get the
> > expression
> > above (in deviations.ecl) right, even
> > 
> > void func1(int);
> > void func2(int);
> > 
> > #define func1() func2(0)
> > #define func2() func1(0)
> > 
> > would be deviated, which I don't think we want. Especially when, in a less
> > contrived scenario, the clash may not easily be visible.
>
> OK, I see the issue for different functions. Does it make sense to say it's
> deliberate when it's the same identifier?
>
> 	void func1(int);
> 	...
> 	#define func1() func1(0)
> 
> Could this be deviated?

I think it makes sense to be clear in deviations.rst and the doc text in
deviations.ecl that we are referring to the same identifier. That we can
do.

I am not sure it is possible to change the ecl rule accordingly to
narrow the check relaxation. If not possible, I'd keep it as it is in
this patch.

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

[Stefano Stabellini]

On Wed, 23 Apr 2025, 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>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

Re: [PATCH v1] misra: add deviation of Rule 5.5

[Stefano Stabellini]

On Wed, 23 Apr 2025, victorm.lira@amd.com wrote:
> From: Federico Serafini <federico.serafini@bugseng.com>
> 
> MISRA C Rule 5.5 states that:
> "Identifiers shall be distinct from macro names".
> 
> A common pattern in Xen is to have a function-like macro that acts as a
> "wrapper" for the function to be called:
> before calling the function, the macro adds additional checks or
> increase/decrease the number of parameters depending on the
> configuration.
> 
> Update ECLAIR configuration and deviations.rst.
> 
> Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
> Signed-off-by: Victor Lira <victorm.lira@amd.com>

This is something we have already discussed in the past and accepted,
but we were missing the ECLAIR configuration for the deviation.

Thanks Federico for producing it.

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

I understand Jan asked for being more precise with the wording and I am
OK with that.

Re: [PATCH v1] misra: add deviation of Rule 10.1 for unary minus

[Stefano Stabellini]

> From: Nicola Vetrini <nicola.vetrini@bugseng.com>
> 
> MISRA C Rule 10.1 states:
> "Operands shall not be of an inappropriate essential type"
> 
> The unary minus operator applied to an unsigned quantity has
> a semantics (wrap around) that is well-known to all Xen developers.
> Thus, this operation is deemed safe.
> 
> No functional change.
> 
> 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>

We only have few instances of this pattern and the few we have are well
understood and certainly deliberate. In practice, this patch reflects
the current coding convention.

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

Jan's request to improve the wording is OK for me.

Re: [PATCH v1] misra: add deviation of Rule 10.1 for unary minus

[Julien Grall]

Hi Victor,

On 23/04/2025 18:54, victorm.lira@amd.com wrote:
> From: Nicola Vetrini <nicola.vetrini@bugseng.com>
> 
> MISRA C Rule 10.1 states:
> "Operands shall not be of an inappropriate essential type"
> 
> The unary minus operator applied to an unsigned quantity has
> a semantics (wrap around) that is well-known to all Xen developers.
> Thus, this operation is deemed safe.
> 
> No functional change.
> 
> 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>
> ---
> Changes v1:
> - add rule title to commit message
> ---
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> Cc: Anthony PERARD <anthony.perard@vates.tech>
> Cc: Michal Orzel <michal.orzel@amd.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Julien Grall <julien@xen.org>
> Cc: Roger Pau Monné <roger.pau@citrix.com>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>
> Cc: Federico Serafini <federico.serafini@bugseng.com>
> Cc: Bertrand Marquis <bertrand.marquis@arm.com>
> ---
>   automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++++++
>   docs/misra/deviations.rst                        | 6 ++++++
>   2 files changed, 12 insertions(+)
> 
> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
> index 303b06203a..2cfce850bd 100644
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -347,6 +347,12 @@ constant expressions are required.\""
>     "any()"}
>   -doc_end
> 
> +-doc_begin="Unary minus operations on non-negative integers have a semantics (wrap around) that is well-known to all Xen developers."
> +-config=MC3A2.R10.1,etypes+={safe,
> +  "stmt(node(unary_operator)&&operator(minus))",
> +  "src_expr(definitely_in(0..))"}
> +-doc_end
> +
>   #
>   # Series 11
>   #
> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
> index cfdd1a9838..c5897e31c5 100644
> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -321,6 +321,12 @@ Deviations related to MISRA C:2012 Rules:
>          If no bits are set, 0 is returned.
>        - Tagged as `safe` for ECLAIR.
> 
> +   * - R10.1
> +     - Applying the unary minus operator to an unsigned quantity has a
> +       semantics (wrap around) that is well-known to all Xen developers.
> +       For this reason, the operation is safe.

I have realized we use similar wording in the rest of the deviations, 
but this is rather fragile argument. "well-known" is very subjective and 
could change over time.

How many violations do we have? Could we deviate them one by one?

Cheers,

-- 
Julien Grall

Re: [PATCH v1] misra: add deviation of Rule 5.5

[Stefano Stabellini]

On Wed, 23 Apr 2025, Stefano Stabellini wrote:
> On Wed, 23 Apr 2025, victorm.lira@amd.com wrote:
> > From: Federico Serafini <federico.serafini@bugseng.com>
> > 
> > MISRA C Rule 5.5 states that:
> > "Identifiers shall be distinct from macro names".
> > 
> > A common pattern in Xen is to have a function-like macro that acts as a
> > "wrapper" for the function to be called:
> > before calling the function, the macro adds additional checks or
> > increase/decrease the number of parameters depending on the
> > configuration.
> > 
> > Update ECLAIR configuration and deviations.rst.
> > 
> > Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
> > Signed-off-by: Victor Lira <victorm.lira@amd.com>
> 
> This is something we have already discussed in the past and accepted,
> but we were missing the ECLAIR configuration for the deviation.
> 
> Thanks Federico for producing it.
> 
> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> 
> I understand Jan asked for being more precise with the wording and I am
> OK with that.

Please remove this last sentence. I meant to say that I am OK with Jan's
request to narrow the deviation, both wording and check. The wording can
be done, I am not sure about the check.

Re: [PATCH v1] misra: add deviation of Rule 10.1 for unary minus

[Nicola Vetrini]

On 2025-04-23 22:48, Julien Grall wrote:
> Hi Victor,
> 
> On 23/04/2025 18:54, victorm.lira@amd.com wrote:
>> From: Nicola Vetrini <nicola.vetrini@bugseng.com>
>> 
>> MISRA C Rule 10.1 states:
>> "Operands shall not be of an inappropriate essential type"
>> 
>> The unary minus operator applied to an unsigned quantity has
>> a semantics (wrap around) that is well-known to all Xen developers.
>> Thus, this operation is deemed safe.
>> 
>> No functional change.
>> 
>> 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>
>> ---
>> Changes v1:
>> - add rule title to commit message
>> ---
>> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>> Cc: Anthony PERARD <anthony.perard@vates.tech>
>> Cc: Michal Orzel <michal.orzel@amd.com>
>> Cc: Jan Beulich <jbeulich@suse.com>
>> Cc: Julien Grall <julien@xen.org>
>> Cc: Roger Pau Monné <roger.pau@citrix.com>
>> Cc: Stefano Stabellini <sstabellini@kernel.org>
>> Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>
>> Cc: Federico Serafini <federico.serafini@bugseng.com>
>> Cc: Bertrand Marquis <bertrand.marquis@arm.com>
>> ---
>>   automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++++++
>>   docs/misra/deviations.rst                        | 6 ++++++
>>   2 files changed, 12 insertions(+)
>> 
>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl 
>> b/automation/eclair_analysis/ECLAIR/deviations.ecl
>> index 303b06203a..2cfce850bd 100644
>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>> @@ -347,6 +347,12 @@ constant expressions are required.\""
>>     "any()"}
>>   -doc_end
>> 
>> +-doc_begin="Unary minus operations on non-negative integers have a 
>> semantics (wrap around) that is well-known to all Xen developers."
>> +-config=MC3A2.R10.1,etypes+={safe,
>> +  "stmt(node(unary_operator)&&operator(minus))",
>> +  "src_expr(definitely_in(0..))"}
>> +-doc_end
>> +
>>   #
>>   # Series 11
>>   #
>> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
>> index cfdd1a9838..c5897e31c5 100644
>> --- a/docs/misra/deviations.rst
>> +++ b/docs/misra/deviations.rst
>> @@ -321,6 +321,12 @@ Deviations related to MISRA C:2012 Rules:
>>          If no bits are set, 0 is returned.
>>        - Tagged as `safe` for ECLAIR.
>> 
>> +   * - R10.1
>> +     - Applying the unary minus operator to an unsigned quantity has 
>> a
>> +       semantics (wrap around) that is well-known to all Xen 
>> developers.
>> +       For this reason, the operation is safe.
> 
> I have realized we use similar wording in the rest of the deviations, 
> but this is rather fragile argument. "well-known" is very subjective 
> and could change over time.
> 
> How many violations do we have? Could we deviate them one by one?
> 

Hi Julien,

around 10 on ARM, but more than 100 on x86 scattered around multiple 
constructs (e.g. not only inside a handful of macros), so I don't think 
it's feasible to deviate them one by one. I do agree that the wording is 
subjective, but it is rather well-defined which toolchains and 
architectures are used (C-language-toolchain.rst). Perhaps a wording 
mentioning the specific assumptions implied here can address your 
concerns?

Thanks,
  Nicola

> Cheers,

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

Re: [PATCH v1] misra: add deviation of Rule 10.1 for unary minus

[Julien Grall]

Hi Nicola,

On 23/04/2025 22:09, Nicola Vetrini wrote:
> On 2025-04-23 22:48, Julien Grall wrote:
>> Hi Victor,
>>
>> On 23/04/2025 18:54, victorm.lira@amd.com wrote:
>>> From: Nicola Vetrini <nicola.vetrini@bugseng.com>
>>>
>>> MISRA C Rule 10.1 states:
>>> "Operands shall not be of an inappropriate essential type"
>>>
>>> The unary minus operator applied to an unsigned quantity has
>>> a semantics (wrap around) that is well-known to all Xen developers.
>>> Thus, this operation is deemed safe.
>>>
>>> No functional change.
>>>
>>> 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>
>>> ---
>>> Changes v1:
>>> - add rule title to commit message
>>> ---
>>> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>>> Cc: Anthony PERARD <anthony.perard@vates.tech>
>>> Cc: Michal Orzel <michal.orzel@amd.com>
>>> Cc: Jan Beulich <jbeulich@suse.com>
>>> Cc: Julien Grall <julien@xen.org>
>>> Cc: Roger Pau Monné <roger.pau@citrix.com>
>>> Cc: Stefano Stabellini <sstabellini@kernel.org>
>>> Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>
>>> Cc: Federico Serafini <federico.serafini@bugseng.com>
>>> Cc: Bertrand Marquis <bertrand.marquis@arm.com>
>>> ---
>>>   automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++++++
>>>   docs/misra/deviations.rst                        | 6 ++++++
>>>   2 files changed, 12 insertions(+)
>>>
>>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/ 
>>> automation/eclair_analysis/ECLAIR/deviations.ecl
>>> index 303b06203a..2cfce850bd 100644
>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> @@ -347,6 +347,12 @@ constant expressions are required.\""
>>>     "any()"}
>>>   -doc_end
>>>
>>> +-doc_begin="Unary minus operations on non-negative integers have a 
>>> semantics (wrap around) that is well-known to all Xen developers."
>>> +-config=MC3A2.R10.1,etypes+={safe,
>>> +  "stmt(node(unary_operator)&&operator(minus))",
>>> +  "src_expr(definitely_in(0..))"}
>>> +-doc_end
>>> +
>>>   #
>>>   # Series 11
>>>   #
>>> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
>>> index cfdd1a9838..c5897e31c5 100644
>>> --- a/docs/misra/deviations.rst
>>> +++ b/docs/misra/deviations.rst
>>> @@ -321,6 +321,12 @@ Deviations related to MISRA C:2012 Rules:
>>>          If no bits are set, 0 is returned.
>>>        - Tagged as `safe` for ECLAIR.
>>>
>>> +   * - R10.1
>>> +     - Applying the unary minus operator to an unsigned quantity has a
>>> +       semantics (wrap around) that is well-known to all Xen 
>>> developers.
>>> +       For this reason, the operation is safe.
>>
>> I have realized we use similar wording in the rest of the deviations, 
>> but this is rather fragile argument. "well-known" is very subjective 
>> and could change over time.
>>
>> How many violations do we have? Could we deviate them one by one?
>>
> 
> Hi Julien,
> 
> around 10 on ARM, but more than 100 on x86 scattered around multiple 
> constructs (e.g. not only inside a handful of macros), so I don't think 
> it's feasible to deviate them one by one. 

Interesting. This seems to contradict what Stefano just wrote:

"
We only have few instances of this pattern and the few we have are well
understood and certainly deliberate.
"

> I do agree that the wording is 
> subjective, but it is rather well-defined which toolchains and 
> architectures are used (C-language-toolchain.rst). Perhaps a wording 
> mentioning the specific assumptions implied here can address your concerns?

If this is well-defined by the toolchains/architectures, then it is a 
better argument than "Xen community knows it".

Cheers,

-- 
Julien Grall

Re: [PATCH v1] misra: add deviation of Rule 10.1 for unary minus

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 4640 bytes --]

On Wed, 23 Apr 2025, Julien Grall wrote:
> Hi Nicola,
> 
> On 23/04/2025 22:09, Nicola Vetrini wrote:
> > On 2025-04-23 22:48, Julien Grall wrote:
> > > Hi Victor,
> > > 
> > > On 23/04/2025 18:54, victorm.lira@amd.com wrote:
> > > > From: Nicola Vetrini <nicola.vetrini@bugseng.com>
> > > > 
> > > > MISRA C Rule 10.1 states:
> > > > "Operands shall not be of an inappropriate essential type"
> > > > 
> > > > The unary minus operator applied to an unsigned quantity has
> > > > a semantics (wrap around) that is well-known to all Xen developers.
> > > > Thus, this operation is deemed safe.
> > > > 
> > > > No functional change.
> > > > 
> > > > 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>
> > > > ---
> > > > Changes v1:
> > > > - add rule title to commit message
> > > > ---
> > > > Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> > > > Cc: Anthony PERARD <anthony.perard@vates.tech>
> > > > Cc: Michal Orzel <michal.orzel@amd.com>
> > > > Cc: Jan Beulich <jbeulich@suse.com>
> > > > Cc: Julien Grall <julien@xen.org>
> > > > Cc: Roger Pau Monné <roger.pau@citrix.com>
> > > > Cc: Stefano Stabellini <sstabellini@kernel.org>
> > > > Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>
> > > > Cc: Federico Serafini <federico.serafini@bugseng.com>
> > > > Cc: Bertrand Marquis <bertrand.marquis@arm.com>
> > > > ---
> > > >   automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++++++
> > > >   docs/misra/deviations.rst                        | 6 ++++++
> > > >   2 files changed, 12 insertions(+)
> > > > 
> > > > diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/
> > > > automation/eclair_analysis/ECLAIR/deviations.ecl
> > > > index 303b06203a..2cfce850bd 100644
> > > > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> > > > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> > > > @@ -347,6 +347,12 @@ constant expressions are required.\""
> > > >     "any()"}
> > > >   -doc_end
> > > > 
> > > > +-doc_begin="Unary minus operations on non-negative integers have a
> > > > semantics (wrap around) that is well-known to all Xen developers."
> > > > +-config=MC3A2.R10.1,etypes+={safe,
> > > > +  "stmt(node(unary_operator)&&operator(minus))",
> > > > +  "src_expr(definitely_in(0..))"}
> > > > +-doc_end
> > > > +
> > > >   #
> > > >   # Series 11
> > > >   #
> > > > diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
> > > > index cfdd1a9838..c5897e31c5 100644
> > > > --- a/docs/misra/deviations.rst
> > > > +++ b/docs/misra/deviations.rst
> > > > @@ -321,6 +321,12 @@ Deviations related to MISRA C:2012 Rules:
> > > >          If no bits are set, 0 is returned.
> > > >        - Tagged as `safe` for ECLAIR.
> > > > 
> > > > +   * - R10.1
> > > > +     - Applying the unary minus operator to an unsigned quantity has a
> > > > +       semantics (wrap around) that is well-known to all Xen
> > > > developers.
> > > > +       For this reason, the operation is safe.
> > > 
> > > I have realized we use similar wording in the rest of the deviations, but
> > > this is rather fragile argument. "well-known" is very subjective and could
> > > change over time.
> > > 
> > > How many violations do we have? Could we deviate them one by one?
> > > 
> > 
> > Hi Julien,
> > 
> > around 10 on ARM, but more than 100 on x86 scattered around multiple
> > constructs (e.g. not only inside a handful of macros), so I don't think it's
> > feasible to deviate them one by one. 
> 
> Interesting. This seems to contradict what Stefano just wrote:
> 
> "
> We only have few instances of this pattern and the few we have are well
> understood and certainly deliberate.
> "

Hi Julien,

Sorry I was going by memory, I should have checked the numbers. There is
an additional issue that there was no overall agreement across all
maintainers to remove all the violations on x86, but now that I see
there are so many it is not really feasible anyway.


> > I do agree that the wording is subjective, but it is rather well-defined
> > which toolchains and architectures are used (C-language-toolchain.rst).
> > Perhaps a wording mentioning the specific assumptions implied here can
> > address your concerns?
> 
> If this is well-defined by the toolchains/architectures, then it is a better
> argument than "Xen community knows it".
 
I also think that "well-defined by the toolchains" is the most important
thing. That should be the real motivation for the deviation. The text
can be improved.

Re: [PATCH v1] misra: add deviation of Rule 5.5

[Jan Beulich]

On 23.04.2025 22:41, Stefano Stabellini wrote:
> On Wed, 23 Apr 2025, Lira, Victor M wrote:
>> Continuing a discussion from before:
>>
>> On 4/22/2025 11:44 PM, Jan Beulich wrote:
>>> Caution: This message originated from an External Source. Use proper caution
>>> when opening attachments, clicking links, or responding.
>>>
>>>
>>> On 23.04.2025 01:43, victorm.lira@amd.com wrote:
>>>>          memmove.
>>>>        - Tagged as `deliberate` for ECLAIR.
>>>>
>>>> +   * - R5.5
>>>> +     - Clashes between function-like macros and function names are
>>>> +       deliberate
>>> They may or may not be deliberate, depending on context. I don't think it's
>>> a
>>> good move to deviate this more widely than necessary. If I get the
>>> expression
>>> above (in deviations.ecl) right, even
>>>
>>> void func1(int);
>>> void func2(int);
>>>
>>> #define func1() func2(0)
>>> #define func2() func1(0)
>>>
>>> would be deviated, which I don't think we want. Especially when, in a less
>>> contrived scenario, the clash may not easily be visible.
>>
>> OK, I see the issue for different functions. Does it make sense to say it's
>> deliberate when it's the same identifier?
>>
>> 	void func1(int);
>> 	...
>> 	#define func1() func1(0)
>>
>> Could this be deviated?
> 
> I think it makes sense to be clear in deviations.rst and the doc text in
> deviations.ecl that we are referring to the same identifier. That we can
> do.
> 
> I am not sure it is possible to change the ecl rule accordingly to
> narrow the check relaxation. If not possible, I'd keep it as it is in
> this patch.

Isn't it a matter of producing a suitable regex? If not, I don't think we
should put in too broad an Eclair rule, but then rather resort to e.g.
SAF comments.

Jan

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

[Jan Beulich]

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.
If so, I expect there's another rule dealing with the remaining concerns.
Then, however, I consider the rule wording insufficient (as leaving an
ambiguity).

Jan

Re: [PATCH v1] misra: add deviation of Rule 5.5

[Andrew Cooper]

On 23/04/2025 7:16 pm, Lira, Victor M wrote:
> Continuing a discussion from before:
>
> On 4/22/2025 11:44 PM, Jan Beulich wrote:
>> Caution: This message originated from an External Source. Use proper
>> caution when opening attachments, clicking links, or responding.
>>
>>
>> On 23.04.2025 01:43, victorm.lira@amd.com wrote:
>>>          memmove.
>>>        - Tagged as `deliberate` for ECLAIR.
>>>
>>> +   * - R5.5
>>> +     - Clashes between function-like macros and function names are
>>> +       deliberate
>> They may or may not be deliberate, depending on context. I don't
>> think it's a
>> good move to deviate this more widely than necessary. If I get the
>> expression
>> above (in deviations.ecl) right, even
>>
>> void func1(int);
>> void func2(int);
>>
>> #define func1() func2(0)
>> #define func2() func1(0)
>>
>> would be deviated, which I don't think we want. Especially when, in a
>> less
>> contrived scenario, the clash may not easily be visible.
> OK, I see the issue for different functions. Does it make sense to say
> it's deliberate when it's the same identifier?
>
>     void func1(int);
>     ...
>     #define func1() func1(0)
>
> Could this be deviated?

The issue here is we've got a load of violations, and different reasoning.

e.g. all the bitops violations are valid and need fixing.  I have a plan
for how to do so, and 0 time.  These are the overwhelming majority of
violations.

pirq_cleanup_check() is horrible.  cpu_has_amd_erraturm is even worse.

In fact, I can't see a single case where the origin code is something we
really want to keep.

I still don't understand the complaint about 'c' as an identifier.

~Andrew

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

[Stefano Stabellini]

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.

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

[Jan Beulich]

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.

Jan

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

[Nicola Vetrini]

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

Hi Jan,

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

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

[Jan Beulich]

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 this could be 
> accomplished also via some gcc trickery on each CU, though I'm not sure 
> how valued that is for Xen.
> 

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

[Nicola Vetrini]

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

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

[Jan Beulich]

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@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,

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

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

[Nicola Vetrini]

On 2025-04-28 11:04, Jan Beulich wrote:
> 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@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,
> 
> 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.
> 

Indeed it is confusing, but likely safe from the perspective of 
preventing UB, which is the main rationale of this rule. For the 
purposes of distinguishing architectures I'd expect a #ifdef __x86_64__ 
or #if defined(__x86_64__) and those are fine, as this only applies to 
#define or #undef.

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

I understand now. There are thousands of locations to be touched to 
remove all uses of reserved identifiers, since they are used quite 
extensively in Xen (A rough estimation is around 1.5k such identifiers, 
with ~900 violations on Arm and ~1000 on x86, without counting their 
occurrences). That is a very disruptive change, even if split very 
finely.

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

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

[Dmytro Prokopchuk1]

Hello, Nicola!

Would you mind if I take part of your patch (related to MISRA C Rule 
21.1) and upstream it?

BR, Dmytro.

On 4/23/25 20: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>
> ---
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> Cc: Anthony PERARD <anthony.perard@vates.tech>
> Cc: Michal Orzel <michal.orzel@amd.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Julien Grall <julien@xen.org>
> Cc: Roger Pau Monné <roger.pau@citrix.com>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>
> Cc: Federico Serafini <federico.serafini@bugseng.com>
> Cc: Bertrand Marquis <bertrand.marquis@arm.com>
> ---
>   .../eclair_analysis/ECLAIR/deviations.ecl     |  9 ++++++-
>   .../eclair_analysis/ECLAIR/monitored.ecl      |  2 ++
>   automation/eclair_analysis/ECLAIR/tagging.ecl |  2 ++
>   docs/misra/deviations.rst                     | 26 ++++++++++++++++++-
>   4 files changed, 37 insertions(+), 2 deletions(-)
> 
> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
> index 2c8fb92713..ffa23b53b7 100644
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -639,8 +639,15 @@ in the expansion."
>   # Series 21.
>   #
> 
> +-doc_begin="Xen does not use C and POSIX libraries:
> +identifiers reserved by these libraries can be used safely, except for those
> +beginning with '__builtin_'."
> +-config=MC3A2.R21.1,macros={safe, "!^__builtin_.*$"}
> +-config=MC3A2.R21.2,declarations={safe, "!^__builtin_.*$"}
> +-doc_end
> +
>   -doc_begin="or, and and xor are reserved identifiers because they constitute alternate
> -spellings for the corresponding operators (they are defined as macros by iso646.h).
> +spellings for the corresponding logical operators (as defined in header 'iso646.h').
>   However, Xen doesn't use standard library headers, so there is no risk of overlap."
>   -config=MC3A2.R21.2,reports+={safe, "any_area(stmt(ref(kind(label)&&^(or|and|xor|not)$)))"}
>   -doc_end
> diff --git a/automation/eclair_analysis/ECLAIR/monitored.ecl b/automation/eclair_analysis/ECLAIR/monitored.ecl
> index 8351996ec8..da229a0d84 100644
> --- a/automation/eclair_analysis/ECLAIR/monitored.ecl
> +++ b/automation/eclair_analysis/ECLAIR/monitored.ecl
> @@ -79,6 +79,8 @@
>   -enable=MC3A2.R20.12
>   -enable=MC3A2.R20.13
>   -enable=MC3A2.R20.14
> +-enable=MC3A2.R21.1
> +-enable=MC3A2.R21.2
>   -enable=MC3A2.R21.3
>   -enable=MC3A2.R21.4
>   -enable=MC3A2.R21.5
> diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/automation/eclair_analysis/ECLAIR/tagging.ecl
> index 1d078d8905..3292bf751e 100644
> --- a/automation/eclair_analysis/ECLAIR/tagging.ecl
> +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
> @@ -88,6 +88,8 @@ MC3A2.R20.11||
>   MC3A2.R20.12||
>   MC3A2.R20.13||
>   MC3A2.R20.14||
> +MC3A2.R21.1||
> +MC3A2.R21.2||
>   MC3A2.R21.3||
>   MC3A2.R21.4||
>   MC3A2.R21.5||
> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
> index fe0b1e10a2..88328eaa8a 100644
> --- 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.
> +
> +   * - R21.2
> +     - Rule 21.2 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 declaring such identifiers except for those beginning with
> +       `__builtin_` for which compilers may perform (wrong) optimizations.
> +     - Tagged as `safe` for ECLAIR.
> +
> +   * - R21.2
> +     - `or`, `and` and `xor` are reserved identifiers because they constitute
> +       alternate spellings for the corresponding logical operators
> +       (as defined in Standard Library header `\<iso646.h\>`). Xen does not use
> +       Standard library headers, so there is no risk of overlap.
> +     - Tagged as `safe` for ECLAIR.
> +
>      * - R21.9
>        - Xen does not use the `bsearch` and `qsort` functions provided by the C
>          Standard Library, but provides in source form its own implementation,
> --
> 2.47.0
> 
> 

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

[Nicola Vetrini]

On 2025-07-02 11:55, Dmytro Prokopchuk1 wrote:
> Hello, Nicola!
> 
> Would you mind if I take part of your patch (related to MISRA C Rule
> 21.1) and upstream it?
> 
> BR, Dmytro.
> 

Hi Dmytro,

I don't mind, though some concerns were raised about the current form of 
the patch (see in particular the last email in the thread). If you are 
able to address those concerns, then maybe this can be upstreamed.

Thanks,
  Nicola

> On 4/23/25 20: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>
>> ---
>> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>> Cc: Anthony PERARD <anthony.perard@vates.tech>
>> Cc: Michal Orzel <michal.orzel@amd.com>
>> Cc: Jan Beulich <jbeulich@suse.com>
>> Cc: Julien Grall <julien@xen.org>
>> Cc: Roger Pau Monné <roger.pau@citrix.com>
>> Cc: Stefano Stabellini <sstabellini@kernel.org>
>> Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>
>> Cc: Federico Serafini <federico.serafini@bugseng.com>
>> Cc: Bertrand Marquis <bertrand.marquis@arm.com>
>> ---
>>   .../eclair_analysis/ECLAIR/deviations.ecl     |  9 ++++++-
>>   .../eclair_analysis/ECLAIR/monitored.ecl      |  2 ++
>>   automation/eclair_analysis/ECLAIR/tagging.ecl |  2 ++
>>   docs/misra/deviations.rst                     | 26 
>> ++++++++++++++++++-
>>   4 files changed, 37 insertions(+), 2 deletions(-)
>> 
>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl 
>> b/automation/eclair_analysis/ECLAIR/deviations.ecl
>> index 2c8fb92713..ffa23b53b7 100644
>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>> @@ -639,8 +639,15 @@ in the expansion."
>>   # Series 21.
>>   #
>> 
>> +-doc_begin="Xen does not use C and POSIX libraries:
>> +identifiers reserved by these libraries can be used safely, except 
>> for those
>> +beginning with '__builtin_'."
>> +-config=MC3A2.R21.1,macros={safe, "!^__builtin_.*$"}
>> +-config=MC3A2.R21.2,declarations={safe, "!^__builtin_.*$"}
>> +-doc_end
>> +
>>   -doc_begin="or, and and xor are reserved identifiers because they 
>> constitute alternate
>> -spellings for the corresponding operators (they are defined as macros 
>> by iso646.h).
>> +spellings for the corresponding logical operators (as defined in 
>> header 'iso646.h').
>>   However, Xen doesn't use standard library headers, so there is no 
>> risk of overlap."
>>   -config=MC3A2.R21.2,reports+={safe, 
>> "any_area(stmt(ref(kind(label)&&^(or|and|xor|not)$)))"}
>>   -doc_end
>> diff --git a/automation/eclair_analysis/ECLAIR/monitored.ecl 
>> b/automation/eclair_analysis/ECLAIR/monitored.ecl
>> index 8351996ec8..da229a0d84 100644
>> --- a/automation/eclair_analysis/ECLAIR/monitored.ecl
>> +++ b/automation/eclair_analysis/ECLAIR/monitored.ecl
>> @@ -79,6 +79,8 @@
>>   -enable=MC3A2.R20.12
>>   -enable=MC3A2.R20.13
>>   -enable=MC3A2.R20.14
>> +-enable=MC3A2.R21.1
>> +-enable=MC3A2.R21.2
>>   -enable=MC3A2.R21.3
>>   -enable=MC3A2.R21.4
>>   -enable=MC3A2.R21.5
>> diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl 
>> b/automation/eclair_analysis/ECLAIR/tagging.ecl
>> index 1d078d8905..3292bf751e 100644
>> --- a/automation/eclair_analysis/ECLAIR/tagging.ecl
>> +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
>> @@ -88,6 +88,8 @@ MC3A2.R20.11||
>>   MC3A2.R20.12||
>>   MC3A2.R20.13||
>>   MC3A2.R20.14||
>> +MC3A2.R21.1||
>> +MC3A2.R21.2||
>>   MC3A2.R21.3||
>>   MC3A2.R21.4||
>>   MC3A2.R21.5||
>> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
>> index fe0b1e10a2..88328eaa8a 100644
>> --- 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.
>> +
>> +   * - R21.2
>> +     - Rule 21.2 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 declaring such identifiers except for those beginning 
>> with
>> +       `__builtin_` for which compilers may perform (wrong) 
>> optimizations.
>> +     - Tagged as `safe` for ECLAIR.
>> +
>> +   * - R21.2
>> +     - `or`, `and` and `xor` are reserved identifiers because they 
>> constitute
>> +       alternate spellings for the corresponding logical operators
>> +       (as defined in Standard Library header `\<iso646.h\>`). Xen 
>> does not use
>> +       Standard library headers, so there is no risk of overlap.
>> +     - Tagged as `safe` for ECLAIR.
>> +
>>      * - R21.9
>>        - Xen does not use the `bsearch` and `qsort` functions provided 
>> by the C
>>          Standard Library, but provides in source form its own 
>> implementation,
>> --
>> 2.47.0
>> 
>> 

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

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

[Dmytro Prokopchuk1]

On 4/23/25 20: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>
> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> Cc: Anthony PERARD <anthony.perard@vates.tech>
> Cc: Michal Orzel <michal.orzel@amd.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Julien Grall <julien@xen.org>
> Cc: Roger Pau Monné <roger.pau@citrix.com>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>
> Cc: Federico Serafini <federico.serafini@bugseng.com>
> Cc: Bertrand Marquis <bertrand.marquis@arm.com>
> ---
>   .../eclair_analysis/ECLAIR/deviations.ecl     |  9 ++++++-
>   .../eclair_analysis/ECLAIR/monitored.ecl      |  2 ++
>   automation/eclair_analysis/ECLAIR/tagging.ecl |  2 ++
>   docs/misra/deviations.rst                     | 26 ++++++++++++++++++-
>   4 files changed, 37 insertions(+), 2 deletions(-)
> 
> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
> index 2c8fb92713..ffa23b53b7 100644
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -639,8 +639,15 @@ in the expansion."
>   # Series 21.
>   #
> 
> +-doc_begin="Xen does not use C and POSIX libraries:
> +identifiers reserved by these libraries can be used safely, except for those
> +beginning with '__builtin_'."
> +-config=MC3A2.R21.1,macros={safe, "!^__builtin_.*$"}
> +-config=MC3A2.R21.2,declarations={safe, "!^__builtin_.*$"}
> +-doc_end
> +
>   -doc_begin="or, and and xor are reserved identifiers because they constitute alternate
> -spellings for the corresponding operators (they are defined as macros by iso646.h).
> +spellings for the corresponding logical operators (as defined in header 'iso646.h').
>   However, Xen doesn't use standard library headers, so there is no risk of overlap."
>   -config=MC3A2.R21.2,reports+={safe, "any_area(stmt(ref(kind(label)&&^(or|and|xor|not)$)))"}
>   -doc_end
> diff --git a/automation/eclair_analysis/ECLAIR/monitored.ecl b/automation/eclair_analysis/ECLAIR/monitored.ecl
> index 8351996ec8..da229a0d84 100644
> --- a/automation/eclair_analysis/ECLAIR/monitored.ecl
> +++ b/automation/eclair_analysis/ECLAIR/monitored.ecl
> @@ -79,6 +79,8 @@
>   -enable=MC3A2.R20.12
>   -enable=MC3A2.R20.13
>   -enable=MC3A2.R20.14
> +-enable=MC3A2.R21.1
> +-enable=MC3A2.R21.2
>   -enable=MC3A2.R21.3
>   -enable=MC3A2.R21.4
>   -enable=MC3A2.R21.5
> diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/automation/eclair_analysis/ECLAIR/tagging.ecl
> index 1d078d8905..3292bf751e 100644
> --- a/automation/eclair_analysis/ECLAIR/tagging.ecl
> +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
> @@ -88,6 +88,8 @@ MC3A2.R20.11||
>   MC3A2.R20.12||
>   MC3A2.R20.13||
>   MC3A2.R20.14||
> +MC3A2.R21.1||
> +MC3A2.R21.2||
>   MC3A2.R21.3||
>   MC3A2.R21.4||
>   MC3A2.R21.5||
> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
> index fe0b1e10a2..88328eaa8a 100644
> --- 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.
> +
> +   * - R21.2
> +     - Rule 21.2 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 declaring such identifiers except for those beginning with
> +       `__builtin_` for which compilers may perform (wrong) optimizations.
> +     - Tagged as `safe` for ECLAIR.
> +
> +   * - R21.2
> +     - `or`, `and` and `xor` are reserved identifiers because they constitute
> +       alternate spellings for the corresponding logical operators
> +       (as defined in Standard Library header `\<iso646.h\>`). Xen does not use
> +       Standard library headers, so there is no risk of overlap.
> +     - Tagged as `safe` for ECLAIR.
> +
>      * - R21.9
>        - Xen does not use the `bsearch` and `qsort` functions provided by the C
>          Standard Library, but provides in source form its own implementation,
> --
> 2.47.0

Hello All!

I tried to play with Rule 21.1 deviations.

After applying the following configurations:

-config=MC3A2.R21.1,macros+={safe, "^offsetof$ || ^(is|to)[a-z]+$ || 
name(NULL) || name(bool) || name(true) || name(false)"}
-config=MC3A2.R21.1,macros+={safe, 
"loc(file(^xen/include/xen/inttypes\\.h$))"}
-config=MC3A2.R21.1,macros+={safe, "loc(file(^xen/include/xen/types\\.h$))"}
-config=MC3A2.R21.1,macros+={safe, "^str[a-z]+$ || ^(v)?sprintf$ || 
^va_[a-z]+$"}

Eclair showed 699 remaining violations.
All of them were related to names beginning with an underscore (_).

It's possible to resolve the rest of them with help of (all, except for 
those beginning with '__builtin_' and '__x86_64__'):

-config=MC3A2.R21.1,macros+={safe, "^_.*$ && !^__builtin_.*$ && 
!^__x86_64__$"}

Probably, the exception list can be extended.

Jan,
I know you don't want to disallow "_all_" such reserved identifiers.
But how to deal with that?

Try to cover all macros? Like this, for example (I assume that there are 
no such reserved macros):
-config=MC3A2.R21.1,macros+={safe, "^.*XEN.*$ || ^.*HYPERVISOR.*$"}


Nicola,
Looks like it's possible to match macros (from ECLAIR User’s Manual)
"guard(): the macro is used as a guard".
I tried to use:
-config=MC3A2.R21.1,macros+={safe, "guard()"}
but it didn't work.
Did I miss something?

Thanks, Dmytro.

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

[Jan Beulich]

On 17.07.2025 22:47, Dmytro Prokopchuk1 wrote:
> 
> 
> On 4/23/25 20: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>
>> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
>> ---
>> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>> Cc: Anthony PERARD <anthony.perard@vates.tech>
>> Cc: Michal Orzel <michal.orzel@amd.com>
>> Cc: Jan Beulich <jbeulich@suse.com>
>> Cc: Julien Grall <julien@xen.org>
>> Cc: Roger Pau Monné <roger.pau@citrix.com>
>> Cc: Stefano Stabellini <sstabellini@kernel.org>
>> Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>
>> Cc: Federico Serafini <federico.serafini@bugseng.com>
>> Cc: Bertrand Marquis <bertrand.marquis@arm.com>
>> ---
>>   .../eclair_analysis/ECLAIR/deviations.ecl     |  9 ++++++-
>>   .../eclair_analysis/ECLAIR/monitored.ecl      |  2 ++
>>   automation/eclair_analysis/ECLAIR/tagging.ecl |  2 ++
>>   docs/misra/deviations.rst                     | 26 ++++++++++++++++++-
>>   4 files changed, 37 insertions(+), 2 deletions(-)
>>
>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
>> index 2c8fb92713..ffa23b53b7 100644
>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>> @@ -639,8 +639,15 @@ in the expansion."
>>   # Series 21.
>>   #
>>
>> +-doc_begin="Xen does not use C and POSIX libraries:
>> +identifiers reserved by these libraries can be used safely, except for those
>> +beginning with '__builtin_'."
>> +-config=MC3A2.R21.1,macros={safe, "!^__builtin_.*$"}
>> +-config=MC3A2.R21.2,declarations={safe, "!^__builtin_.*$"}
>> +-doc_end
>> +
>>   -doc_begin="or, and and xor are reserved identifiers because they constitute alternate
>> -spellings for the corresponding operators (they are defined as macros by iso646.h).
>> +spellings for the corresponding logical operators (as defined in header 'iso646.h').
>>   However, Xen doesn't use standard library headers, so there is no risk of overlap."
>>   -config=MC3A2.R21.2,reports+={safe, "any_area(stmt(ref(kind(label)&&^(or|and|xor|not)$)))"}
>>   -doc_end
>> diff --git a/automation/eclair_analysis/ECLAIR/monitored.ecl b/automation/eclair_analysis/ECLAIR/monitored.ecl
>> index 8351996ec8..da229a0d84 100644
>> --- a/automation/eclair_analysis/ECLAIR/monitored.ecl
>> +++ b/automation/eclair_analysis/ECLAIR/monitored.ecl
>> @@ -79,6 +79,8 @@
>>   -enable=MC3A2.R20.12
>>   -enable=MC3A2.R20.13
>>   -enable=MC3A2.R20.14
>> +-enable=MC3A2.R21.1
>> +-enable=MC3A2.R21.2
>>   -enable=MC3A2.R21.3
>>   -enable=MC3A2.R21.4
>>   -enable=MC3A2.R21.5
>> diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/automation/eclair_analysis/ECLAIR/tagging.ecl
>> index 1d078d8905..3292bf751e 100644
>> --- a/automation/eclair_analysis/ECLAIR/tagging.ecl
>> +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
>> @@ -88,6 +88,8 @@ MC3A2.R20.11||
>>   MC3A2.R20.12||
>>   MC3A2.R20.13||
>>   MC3A2.R20.14||
>> +MC3A2.R21.1||
>> +MC3A2.R21.2||
>>   MC3A2.R21.3||
>>   MC3A2.R21.4||
>>   MC3A2.R21.5||
>> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
>> index fe0b1e10a2..88328eaa8a 100644
>> --- 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.
>> +
>> +   * - R21.2
>> +     - Rule 21.2 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 declaring such identifiers except for those beginning with
>> +       `__builtin_` for which compilers may perform (wrong) optimizations.
>> +     - Tagged as `safe` for ECLAIR.
>> +
>> +   * - R21.2
>> +     - `or`, `and` and `xor` are reserved identifiers because they constitute
>> +       alternate spellings for the corresponding logical operators
>> +       (as defined in Standard Library header `\<iso646.h\>`). Xen does not use
>> +       Standard library headers, so there is no risk of overlap.
>> +     - Tagged as `safe` for ECLAIR.
>> +
>>      * - R21.9
>>        - Xen does not use the `bsearch` and `qsort` functions provided by the C
>>          Standard Library, but provides in source form its own implementation,
>> --
>> 2.47.0
> 
> Hello All!
> 
> I tried to play with Rule 21.1 deviations.
> 
> After applying the following configurations:
> 
> -config=MC3A2.R21.1,macros+={safe, "^offsetof$ || ^(is|to)[a-z]+$ || 
> name(NULL) || name(bool) || name(true) || name(false)"}
> -config=MC3A2.R21.1,macros+={safe, 
> "loc(file(^xen/include/xen/inttypes\\.h$))"}
> -config=MC3A2.R21.1,macros+={safe, "loc(file(^xen/include/xen/types\\.h$))"}
> -config=MC3A2.R21.1,macros+={safe, "^str[a-z]+$ || ^(v)?sprintf$ || 
> ^va_[a-z]+$"}

Can you spell these out in words? I can only vaguely interpret these Eclair
patterns, sorry.

> Eclair showed 699 remaining violations.
> All of them were related to names beginning with an underscore (_).
> 
> It's possible to resolve the rest of them with help of (all, except for 
> those beginning with '__builtin_' and '__x86_64__'):
> 
> -config=MC3A2.R21.1,macros+={safe, "^_.*$ && !^__builtin_.*$ && 
> !^__x86_64__$"}
> 
> Probably, the exception list can be extended.
> 
> Jan,
> I know you don't want to disallow "_all_" such reserved identifiers.
> But how to deal with that?

How do I not want this? I've been arguing for years that we should respect
the reserved name spaces. (Did you perhaps mean "... you don't want to
deviate ..."?) There are exceptions, yes, e.g. ...

> Try to cover all macros? Like this, for example (I assume that there are 
> no such reserved macros):
> -config=MC3A2.R21.1,macros+={safe, "^.*XEN.*$ || ^.*HYPERVISOR.*$"}

... anything we may have (wrongly) introduced into the public headers. We
can't very well change naming there.

Jan

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

[Dmytro Prokopchuk1]

On 7/18/25 08:31, Jan Beulich wrote:
> On 17.07.2025 22:47, Dmytro Prokopchuk1 wrote:
>>
>>
>> On 4/23/25 20: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>
>>> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
>>> ---
>>> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>>> Cc: Anthony PERARD <anthony.perard@vates.tech>
>>> Cc: Michal Orzel <michal.orzel@amd.com>
>>> Cc: Jan Beulich <jbeulich@suse.com>
>>> Cc: Julien Grall <julien@xen.org>
>>> Cc: Roger Pau Monné <roger.pau@citrix.com>
>>> Cc: Stefano Stabellini <sstabellini@kernel.org>
>>> Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>
>>> Cc: Federico Serafini <federico.serafini@bugseng.com>
>>> Cc: Bertrand Marquis <bertrand.marquis@arm.com>
>>> ---
>>>    .../eclair_analysis/ECLAIR/deviations.ecl     |  9 ++++++-
>>>    .../eclair_analysis/ECLAIR/monitored.ecl      |  2 ++
>>>    automation/eclair_analysis/ECLAIR/tagging.ecl |  2 ++
>>>    docs/misra/deviations.rst                     | 26 ++++++++++++++++++-
>>>    4 files changed, 37 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> index 2c8fb92713..ffa23b53b7 100644
>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> @@ -639,8 +639,15 @@ in the expansion."
>>>    # Series 21.
>>>    #
>>>
>>> +-doc_begin="Xen does not use C and POSIX libraries:
>>> +identifiers reserved by these libraries can be used safely, except for those
>>> +beginning with '__builtin_'."
>>> +-config=MC3A2.R21.1,macros={safe, "!^__builtin_.*$"}
>>> +-config=MC3A2.R21.2,declarations={safe, "!^__builtin_.*$"}
>>> +-doc_end
>>> +
>>>    -doc_begin="or, and and xor are reserved identifiers because they constitute alternate
>>> -spellings for the corresponding operators (they are defined as macros by iso646.h).
>>> +spellings for the corresponding logical operators (as defined in header 'iso646.h').
>>>    However, Xen doesn't use standard library headers, so there is no risk of overlap."
>>>    -config=MC3A2.R21.2,reports+={safe, "any_area(stmt(ref(kind(label)&&^(or|and|xor|not)$)))"}
>>>    -doc_end
>>> diff --git a/automation/eclair_analysis/ECLAIR/monitored.ecl b/automation/eclair_analysis/ECLAIR/monitored.ecl
>>> index 8351996ec8..da229a0d84 100644
>>> --- a/automation/eclair_analysis/ECLAIR/monitored.ecl
>>> +++ b/automation/eclair_analysis/ECLAIR/monitored.ecl
>>> @@ -79,6 +79,8 @@
>>>    -enable=MC3A2.R20.12
>>>    -enable=MC3A2.R20.13
>>>    -enable=MC3A2.R20.14
>>> +-enable=MC3A2.R21.1
>>> +-enable=MC3A2.R21.2
>>>    -enable=MC3A2.R21.3
>>>    -enable=MC3A2.R21.4
>>>    -enable=MC3A2.R21.5
>>> diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/automation/eclair_analysis/ECLAIR/tagging.ecl
>>> index 1d078d8905..3292bf751e 100644
>>> --- a/automation/eclair_analysis/ECLAIR/tagging.ecl
>>> +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
>>> @@ -88,6 +88,8 @@ MC3A2.R20.11||
>>>    MC3A2.R20.12||
>>>    MC3A2.R20.13||
>>>    MC3A2.R20.14||
>>> +MC3A2.R21.1||
>>> +MC3A2.R21.2||
>>>    MC3A2.R21.3||
>>>    MC3A2.R21.4||
>>>    MC3A2.R21.5||
>>> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
>>> index fe0b1e10a2..88328eaa8a 100644
>>> --- 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.
>>> +
>>> +   * - R21.2
>>> +     - Rule 21.2 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 declaring such identifiers except for those beginning with
>>> +       `__builtin_` for which compilers may perform (wrong) optimizations.
>>> +     - Tagged as `safe` for ECLAIR.
>>> +
>>> +   * - R21.2
>>> +     - `or`, `and` and `xor` are reserved identifiers because they constitute
>>> +       alternate spellings for the corresponding logical operators
>>> +       (as defined in Standard Library header `\<iso646.h\>`). Xen does not use
>>> +       Standard library headers, so there is no risk of overlap.
>>> +     - Tagged as `safe` for ECLAIR.
>>> +
>>>       * - R21.9
>>>         - Xen does not use the `bsearch` and `qsort` functions provided by the C
>>>           Standard Library, but provides in source form its own implementation,
>>> --
>>> 2.47.0
>>
>> Hello All!
>>
>> I tried to play with Rule 21.1 deviations.
>>
>> After applying the following configurations:
>>
>> -config=MC3A2.R21.1,macros+={safe, "^offsetof$ || ^(is|to)[a-z]+$ ||
>> name(NULL) || name(bool) || name(true) || name(false)"}
>> -config=MC3A2.R21.1,macros+={safe,
>> "loc(file(^xen/include/xen/inttypes\\.h$))"}
>> -config=MC3A2.R21.1,macros+={safe, "loc(file(^xen/include/xen/types\\.h$))"}
>> -config=MC3A2.R21.1,macros+={safe, "^str[a-z]+$ || ^(v)?sprintf$ ||
>> ^va_[a-z]+$"}
> 
> Can you spell these out in words? I can only vaguely interpret these Eclair
> patterns, sorry.
Yes, sure.

That means to deviate the following macros:
- offsetof
- begin with either ‘is’ or ‘to’ followed by a lowercase letters 
(islower, isdigit, tolower, toupper, etc.)
- NULL
- bool
- true
- false
- all PRI/SCN macros for printing/scanning format specifiers from header 
file xen/include/xen/inttypes.h
- all macros from header file xen/include/xen/types.h (limits: 
UINT8_MAX, INT_MAX, LONG_MIN, etc.)
- begin with 'str' followed by a lowercase letters (string functions)
- sprintf/vsprintf
- begin with 'va_' followed by a lowercase letters (va_copy, va_start, 
va_end, va_arg)

> 
>> Eclair showed 699 remaining violations.
>> All of them were related to names beginning with an underscore (_).
>>
>> It's possible to resolve the rest of them with help of (all, except for
>> those beginning with '__builtin_' and '__x86_64__'):
>>
>> -config=MC3A2.R21.1,macros+={safe, "^_.*$ && !^__builtin_.*$ &&
>> !^__x86_64__$"}
>>
>> Probably, the exception list can be extended.
>>
>> Jan,
>> I know you don't want to disallow "_all_" such reserved identifiers.
>> But how to deal with that?
> 
> How do I not want this? I've been arguing for years that we should respect
> the reserved name spaces. (Did you perhaps mean "... you don't want to
> deviate ..."?) There are exceptions, yes, e.g. ...
> 
Yes, I meant about deviations. Sorry.

>> Try to cover all macros? Like this, for example (I assume that there are
>> no such reserved macros):
>> -config=MC3A2.R21.1,macros+={safe, "^.*XEN.*$ || ^.*HYPERVISOR.*$"}
> 
> ... anything we may have (wrongly) introduced into the public headers. We
> can't very well change naming there.
Looks like the only way is to deviate all macros (that are currently 
used in Xen), tag rule as "clean" and prohibit using reserved names in 
the future.

Any suggestions?

Dmytro

> 
> Jan

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

[Dmytro Prokopchuk1]

On 7/18/25 12:17, Dmytro Prokopchuk wrote:
> 
> 
> On 7/18/25 08:31, Jan Beulich wrote:
>> On 17.07.2025 22:47, Dmytro Prokopchuk1 wrote:
>>>
>>>
>>> On 4/23/25 20: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>
>>>> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
>>>> ---
>>>> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>>>> Cc: Anthony PERARD <anthony.perard@vates.tech>
>>>> Cc: Michal Orzel <michal.orzel@amd.com>
>>>> Cc: Jan Beulich <jbeulich@suse.com>
>>>> Cc: Julien Grall <julien@xen.org>
>>>> Cc: Roger Pau Monné <roger.pau@citrix.com>
>>>> Cc: Stefano Stabellini <sstabellini@kernel.org>
>>>> Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>
>>>> Cc: Federico Serafini <federico.serafini@bugseng.com>
>>>> Cc: Bertrand Marquis <bertrand.marquis@arm.com>
>>>> ---
>>>>    .../eclair_analysis/ECLAIR/deviations.ecl     |  9 ++++++-
>>>>    .../eclair_analysis/ECLAIR/monitored.ecl      |  2 ++
>>>>    automation/eclair_analysis/ECLAIR/tagging.ecl |  2 ++
>>>>    docs/misra/deviations.rst                     | 26 ++++++++++++++ 
>>>> ++++-
>>>>    4 files changed, 37 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/ 
>>>> automation/eclair_analysis/ECLAIR/deviations.ecl
>>>> index 2c8fb92713..ffa23b53b7 100644
>>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>> @@ -639,8 +639,15 @@ in the expansion."
>>>>    # Series 21.
>>>>    #
>>>>
>>>> +-doc_begin="Xen does not use C and POSIX libraries:
>>>> +identifiers reserved by these libraries can be used safely, except 
>>>> for those
>>>> +beginning with '__builtin_'."
>>>> +-config=MC3A2.R21.1,macros={safe, "!^__builtin_.*$"}
>>>> +-config=MC3A2.R21.2,declarations={safe, "!^__builtin_.*$"}
>>>> +-doc_end
>>>> +
>>>>    -doc_begin="or, and and xor are reserved identifiers because they 
>>>> constitute alternate
>>>> -spellings for the corresponding operators (they are defined as 
>>>> macros by iso646.h).
>>>> +spellings for the corresponding logical operators (as defined in 
>>>> header 'iso646.h').
>>>>    However, Xen doesn't use standard library headers, so there is no 
>>>> risk of overlap."
>>>>    -config=MC3A2.R21.2,reports+={safe, 
>>>> "any_area(stmt(ref(kind(label)&&^(or|and|xor|not)$)))"}
>>>>    -doc_end
>>>> diff --git a/automation/eclair_analysis/ECLAIR/monitored.ecl b/ 
>>>> automation/eclair_analysis/ECLAIR/monitored.ecl
>>>> index 8351996ec8..da229a0d84 100644
>>>> --- a/automation/eclair_analysis/ECLAIR/monitored.ecl
>>>> +++ b/automation/eclair_analysis/ECLAIR/monitored.ecl
>>>> @@ -79,6 +79,8 @@
>>>>    -enable=MC3A2.R20.12
>>>>    -enable=MC3A2.R20.13
>>>>    -enable=MC3A2.R20.14
>>>> +-enable=MC3A2.R21.1
>>>> +-enable=MC3A2.R21.2
>>>>    -enable=MC3A2.R21.3
>>>>    -enable=MC3A2.R21.4
>>>>    -enable=MC3A2.R21.5
>>>> diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/ 
>>>> automation/eclair_analysis/ECLAIR/tagging.ecl
>>>> index 1d078d8905..3292bf751e 100644
>>>> --- a/automation/eclair_analysis/ECLAIR/tagging.ecl
>>>> +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
>>>> @@ -88,6 +88,8 @@ MC3A2.R20.11||
>>>>    MC3A2.R20.12||
>>>>    MC3A2.R20.13||
>>>>    MC3A2.R20.14||
>>>> +MC3A2.R21.1||
>>>> +MC3A2.R21.2||
>>>>    MC3A2.R21.3||
>>>>    MC3A2.R21.4||
>>>>    MC3A2.R21.5||
>>>> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
>>>> index fe0b1e10a2..88328eaa8a 100644
>>>> --- 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.
>>>> +
>>>> +   * - R21.2
>>>> +     - Rule 21.2 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 declaring such identifiers except for those beginning 
>>>> with
>>>> +       `__builtin_` for which compilers may perform (wrong) 
>>>> optimizations.
>>>> +     - Tagged as `safe` for ECLAIR.
>>>> +
>>>> +   * - R21.2
>>>> +     - `or`, `and` and `xor` are reserved identifiers because they 
>>>> constitute
>>>> +       alternate spellings for the corresponding logical operators
>>>> +       (as defined in Standard Library header `\<iso646.h\>`). Xen 
>>>> does not use
>>>> +       Standard library headers, so there is no risk of overlap.
>>>> +     - Tagged as `safe` for ECLAIR.
>>>> +
>>>>       * - R21.9
>>>>         - Xen does not use the `bsearch` and `qsort` functions 
>>>> provided by the C
>>>>           Standard Library, but provides in source form its own 
>>>> implementation,
>>>> -- 
>>>> 2.47.0
>>>
>>> Hello All!
>>>
>>> I tried to play with Rule 21.1 deviations.
>>>
>>> After applying the following configurations:
>>>
>>> -config=MC3A2.R21.1,macros+={safe, "^offsetof$ || ^(is|to)[a-z]+$ ||
>>> name(NULL) || name(bool) || name(true) || name(false)"}
>>> -config=MC3A2.R21.1,macros+={safe,
>>> "loc(file(^xen/include/xen/inttypes\\.h$))"}
>>> -config=MC3A2.R21.1,macros+={safe, "loc(file(^xen/include/xen/types\ 
>>> \.h$))"}
>>> -config=MC3A2.R21.1,macros+={safe, "^str[a-z]+$ || ^(v)?sprintf$ ||
>>> ^va_[a-z]+$"}
>>
>> Can you spell these out in words? I can only vaguely interpret these 
>> Eclair
>> patterns, sorry.
> Yes, sure.
> 
> That means to deviate the following macros:
> - offsetof
> - begin with either ‘is’ or ‘to’ followed by a lowercase letters 
> (islower, isdigit, tolower, toupper, etc.)
> - NULL
> - bool
> - true
> - false
> - all PRI/SCN macros for printing/scanning format specifiers from header 
> file xen/include/xen/inttypes.h
> - all macros from header file xen/include/xen/types.h (limits: 
> UINT8_MAX, INT_MAX, LONG_MIN, etc.)
> - begin with 'str' followed by a lowercase letters (string functions)
> - sprintf/vsprintf
> - begin with 'va_' followed by a lowercase letters (va_copy, va_start, 
> va_end, va_arg)
> 
>>
>>> Eclair showed 699 remaining violations.
>>> All of them were related to names beginning with an underscore (_).
>>>
>>> It's possible to resolve the rest of them with help of (all, except for
>>> those beginning with '__builtin_' and '__x86_64__'):
>>>
>>> -config=MC3A2.R21.1,macros+={safe, "^_.*$ && !^__builtin_.*$ &&
>>> !^__x86_64__$"}
>>>
>>> Probably, the exception list can be extended.
>>>
>>> Jan,
>>> I know you don't want to disallow "_all_" such reserved identifiers.
>>> But how to deal with that?
>>
>> How do I not want this? I've been arguing for years that we should 
>> respect
>> the reserved name spaces. (Did you perhaps mean "... you don't want to
>> deviate ..."?) There are exceptions, yes, e.g. ...
>>
> Yes, I meant about deviations. Sorry.
> 
>>> Try to cover all macros? Like this, for example (I assume that there are
>>> no such reserved macros):
>>> -config=MC3A2.R21.1,macros+={safe, "^.*XEN.*$ || ^.*HYPERVISOR.*$"}
>>
>> ... anything we may have (wrongly) introduced into the public headers. We
>> can't very well change naming there.
> Looks like the only way is to deviate all macros (that are currently 
> used in Xen), tag rule as "clean" and prohibit using reserved names in 
> the future.
> 
> Any suggestions?
> 
> Dmytro

BTW, not all violations are in public headers.
Probably, they could be fixed in code.
But the number of them is huge...

Dmytro

> 
>>
>> Jan

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

[Jan Beulich]

On 18.07.2025 11:17, Dmytro Prokopchuk1 wrote:
> On 7/18/25 08:31, Jan Beulich wrote:
>> On 17.07.2025 22:47, Dmytro Prokopchuk1 wrote:
>>> I tried to play with Rule 21.1 deviations.
>>>
>>> After applying the following configurations:
>>>
>>> -config=MC3A2.R21.1,macros+={safe, "^offsetof$ || ^(is|to)[a-z]+$ ||
>>> name(NULL) || name(bool) || name(true) || name(false)"}
>>> -config=MC3A2.R21.1,macros+={safe,
>>> "loc(file(^xen/include/xen/inttypes\\.h$))"}
>>> -config=MC3A2.R21.1,macros+={safe, "loc(file(^xen/include/xen/types\\.h$))"}
>>> -config=MC3A2.R21.1,macros+={safe, "^str[a-z]+$ || ^(v)?sprintf$ ||
>>> ^va_[a-z]+$"}
>>
>> Can you spell these out in words? I can only vaguely interpret these Eclair
>> patterns, sorry.
> Yes, sure.
> 
> That means to deviate the following macros:
> - offsetof
> - begin with either ‘is’ or ‘to’ followed by a lowercase letters 
> (islower, isdigit, tolower, toupper, etc.)
> - NULL
> - bool
> - true
> - false
> - all PRI/SCN macros for printing/scanning format specifiers from header 
> file xen/include/xen/inttypes.h
> - all macros from header file xen/include/xen/types.h (limits: 
> UINT8_MAX, INT_MAX, LONG_MIN, etc.)
> - begin with 'str' followed by a lowercase letters (string functions)
> - sprintf/vsprintf
> - begin with 'va_' followed by a lowercase letters (va_copy, va_start, 
> va_end, va_arg)

That's all stuff the library defines, when there is an (external) library.
I Xen we have (or should I say "we are") the library. Why are we not
permitted to define what a library is expected to define? How would one
go about dealing with an actual library implementation, when it is not
allowed to define anything a library is expected to define?

Jan

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

[Nicola Vetrini]

On 2025-07-18 11:28, Dmytro Prokopchuk1 wrote:
> On 7/18/25 12:17, Dmytro Prokopchuk wrote:
>> 
>> 
>> On 7/18/25 08:31, Jan Beulich wrote:
>>> On 17.07.2025 22:47, Dmytro Prokopchuk1 wrote:
>>>> 
>>>> 
>>>> On 4/23/25 20: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>
>>>>> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
>>>>> ---
>>>>> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>>>>> Cc: Anthony PERARD <anthony.perard@vates.tech>
>>>>> Cc: Michal Orzel <michal.orzel@amd.com>
>>>>> Cc: Jan Beulich <jbeulich@suse.com>
>>>>> Cc: Julien Grall <julien@xen.org>
>>>>> Cc: Roger Pau Monné <roger.pau@citrix.com>
>>>>> Cc: Stefano Stabellini <sstabellini@kernel.org>
>>>>> Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>
>>>>> Cc: Federico Serafini <federico.serafini@bugseng.com>
>>>>> Cc: Bertrand Marquis <bertrand.marquis@arm.com>
>>>>> ---
>>>>>    .../eclair_analysis/ECLAIR/deviations.ecl     |  9 ++++++-
>>>>>    .../eclair_analysis/ECLAIR/monitored.ecl      |  2 ++
>>>>>    automation/eclair_analysis/ECLAIR/tagging.ecl |  2 ++
>>>>>    docs/misra/deviations.rst                     | 26 
>>>>> ++++++++++++++
>>>>> ++++-
>>>>>    4 files changed, 37 insertions(+), 2 deletions(-)
>>>>> 
>>>>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/
>>>>> automation/eclair_analysis/ECLAIR/deviations.ecl
>>>>> index 2c8fb92713..ffa23b53b7 100644
>>>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>>> @@ -639,8 +639,15 @@ in the expansion."
>>>>>    # Series 21.
>>>>>    #
>>>>> 
>>>>> +-doc_begin="Xen does not use C and POSIX libraries:
>>>>> +identifiers reserved by these libraries can be used safely, except
>>>>> for those
>>>>> +beginning with '__builtin_'."
>>>>> +-config=MC3A2.R21.1,macros={safe, "!^__builtin_.*$"}
>>>>> +-config=MC3A2.R21.2,declarations={safe, "!^__builtin_.*$"}
>>>>> +-doc_end
>>>>> +
>>>>>    -doc_begin="or, and and xor are reserved identifiers because 
>>>>> they
>>>>> constitute alternate
>>>>> -spellings for the corresponding operators (they are defined as
>>>>> macros by iso646.h).
>>>>> +spellings for the corresponding logical operators (as defined in
>>>>> header 'iso646.h').
>>>>>    However, Xen doesn't use standard library headers, so there is 
>>>>> no
>>>>> risk of overlap."
>>>>>    -config=MC3A2.R21.2,reports+={safe,
>>>>> "any_area(stmt(ref(kind(label)&&^(or|and|xor|not)$)))"}
>>>>>    -doc_end
>>>>> diff --git a/automation/eclair_analysis/ECLAIR/monitored.ecl b/
>>>>> automation/eclair_analysis/ECLAIR/monitored.ecl
>>>>> index 8351996ec8..da229a0d84 100644
>>>>> --- a/automation/eclair_analysis/ECLAIR/monitored.ecl
>>>>> +++ b/automation/eclair_analysis/ECLAIR/monitored.ecl
>>>>> @@ -79,6 +79,8 @@
>>>>>    -enable=MC3A2.R20.12
>>>>>    -enable=MC3A2.R20.13
>>>>>    -enable=MC3A2.R20.14
>>>>> +-enable=MC3A2.R21.1
>>>>> +-enable=MC3A2.R21.2
>>>>>    -enable=MC3A2.R21.3
>>>>>    -enable=MC3A2.R21.4
>>>>>    -enable=MC3A2.R21.5
>>>>> diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/
>>>>> automation/eclair_analysis/ECLAIR/tagging.ecl
>>>>> index 1d078d8905..3292bf751e 100644
>>>>> --- a/automation/eclair_analysis/ECLAIR/tagging.ecl
>>>>> +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
>>>>> @@ -88,6 +88,8 @@ MC3A2.R20.11||
>>>>>    MC3A2.R20.12||
>>>>>    MC3A2.R20.13||
>>>>>    MC3A2.R20.14||
>>>>> +MC3A2.R21.1||
>>>>> +MC3A2.R21.2||
>>>>>    MC3A2.R21.3||
>>>>>    MC3A2.R21.4||
>>>>>    MC3A2.R21.5||
>>>>> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
>>>>> index fe0b1e10a2..88328eaa8a 100644
>>>>> --- 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.
>>>>> +
>>>>> +   * - R21.2
>>>>> +     - Rule 21.2 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 declaring such identifiers except for those beginning
>>>>> with
>>>>> +       `__builtin_` for which compilers may perform (wrong)
>>>>> optimizations.
>>>>> +     - Tagged as `safe` for ECLAIR.
>>>>> +
>>>>> +   * - R21.2
>>>>> +     - `or`, `and` and `xor` are reserved identifiers because they
>>>>> constitute
>>>>> +       alternate spellings for the corresponding logical operators
>>>>> +       (as defined in Standard Library header `\<iso646.h\>`). Xen
>>>>> does not use
>>>>> +       Standard library headers, so there is no risk of overlap.
>>>>> +     - Tagged as `safe` for ECLAIR.
>>>>> +
>>>>>       * - R21.9
>>>>>         - Xen does not use the `bsearch` and `qsort` functions
>>>>> provided by the C
>>>>>           Standard Library, but provides in source form its own
>>>>> implementation,
>>>>> --
>>>>> 2.47.0
>>>> 
>>>> Hello All!
>>>> 
>>>> I tried to play with Rule 21.1 deviations.
>>>> 
>>>> After applying the following configurations:
>>>> 
>>>> -config=MC3A2.R21.1,macros+={safe, "^offsetof$ || ^(is|to)[a-z]+$ ||
>>>> name(NULL) || name(bool) || name(true) || name(false)"}
>>>> -config=MC3A2.R21.1,macros+={safe,
>>>> "loc(file(^xen/include/xen/inttypes\\.h$))"}
>>>> -config=MC3A2.R21.1,macros+={safe, "loc(file(^xen/include/xen/types\
>>>> \.h$))"}
>>>> -config=MC3A2.R21.1,macros+={safe, "^str[a-z]+$ || ^(v)?sprintf$ ||
>>>> ^va_[a-z]+$"}
>>> 
>>> Can you spell these out in words? I can only vaguely interpret these
>>> Eclair
>>> patterns, sorry.
>> Yes, sure.
>> 
>> That means to deviate the following macros:
>> - offsetof
>> - begin with either ‘is’ or ‘to’ followed by a lowercase letters
>> (islower, isdigit, tolower, toupper, etc.)
>> - NULL
>> - bool
>> - true
>> - false
>> - all PRI/SCN macros for printing/scanning format specifiers from 
>> header
>> file xen/include/xen/inttypes.h
>> - all macros from header file xen/include/xen/types.h (limits:
>> UINT8_MAX, INT_MAX, LONG_MIN, etc.)
>> - begin with 'str' followed by a lowercase letters (string functions)
>> - sprintf/vsprintf
>> - begin with 'va_' followed by a lowercase letters (va_copy, va_start,
>> va_end, va_arg)
>> 
>>> 
>>>> Eclair showed 699 remaining violations.
>>>> All of them were related to names beginning with an underscore (_).
>>>> 
>>>> It's possible to resolve the rest of them with help of (all, except 
>>>> for
>>>> those beginning with '__builtin_' and '__x86_64__'):
>>>> 
>>>> -config=MC3A2.R21.1,macros+={safe, "^_.*$ && !^__builtin_.*$ &&
>>>> !^__x86_64__$"}
>>>> 
>>>> Probably, the exception list can be extended.
>>>> 
>>>> Jan,
>>>> I know you don't want to disallow "_all_" such reserved identifiers.
>>>> But how to deal with that?
>>> 
>>> How do I not want this? I've been arguing for years that we should
>>> respect
>>> the reserved name spaces. (Did you perhaps mean "... you don't want 
>>> to
>>> deviate ..."?) There are exceptions, yes, e.g. ...
>>> 
>> Yes, I meant about deviations. Sorry.
>> 
>>>> Try to cover all macros? Like this, for example (I assume that there 
>>>> are
>>>> no such reserved macros):
>>>> -config=MC3A2.R21.1,macros+={safe, "^.*XEN.*$ || ^.*HYPERVISOR.*$"}
>>> 
>>> ... anything we may have (wrongly) introduced into the public 
>>> headers. We
>>> can't very well change naming there.
>> Looks like the only way is to deviate all macros (that are currently
>> used in Xen), tag rule as "clean" and prohibit using reserved names in
>> the future.
>> 
>> Any suggestions?
>> 
>> Dmytro
> 
> BTW, not all violations are in public headers.
> Probably, they could be fixed in code.
> But the number of them is huge...
> 

This is precisely the issue I was pointing out when you offered to 
respin this patch. Yes, Xen could fix those rather than deviate, but the 
sheer number of violations makes this in my opinion unfeasible.

> Dmytro
> 
>> 
>>> 
>>> Jan

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

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

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 10498 bytes --]

On 7/18/25 07:08, Nicola Vetrini wrote:
> On 2025-07-18 11:28, Dmytro Prokopchuk1 wrote:
>> On 7/18/25 12:17, Dmytro Prokopchuk wrote:
>>>
>>>
>>> On 7/18/25 08:31, Jan Beulich wrote:
>>>> On 17.07.2025 22:47, Dmytro Prokopchuk1 wrote:
>>>>>
>>>>>
>>>>> On 4/23/25 20: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>
>>>>>> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
>>>>>> ---
>>>>>> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>>>>>> Cc: Anthony PERARD <anthony.perard@vates.tech>
>>>>>> Cc: Michal Orzel <michal.orzel@amd.com>
>>>>>> Cc: Jan Beulich <jbeulich@suse.com>
>>>>>> Cc: Julien Grall <julien@xen.org>
>>>>>> Cc: Roger Pau Monné <roger.pau@citrix.com>
>>>>>> Cc: Stefano Stabellini <sstabellini@kernel.org>
>>>>>> Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>
>>>>>> Cc: Federico Serafini <federico.serafini@bugseng.com>
>>>>>> Cc: Bertrand Marquis <bertrand.marquis@arm.com>
>>>>>> ---
>>>>>>    .../eclair_analysis/ECLAIR/deviations.ecl     |  9 ++++++-
>>>>>>    .../eclair_analysis/ECLAIR/monitored.ecl      |  2 ++
>>>>>>    automation/eclair_analysis/ECLAIR/tagging.ecl |  2 ++
>>>>>>    docs/misra/deviations.rst                     | 26 
>>>>>> ++++++++++++++
>>>>>> ++++-
>>>>>>    4 files changed, 37 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/
>>>>>> automation/eclair_analysis/ECLAIR/deviations.ecl
>>>>>> index 2c8fb92713..ffa23b53b7 100644
>>>>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>>>> @@ -639,8 +639,15 @@ in the expansion."
>>>>>>    # Series 21.
>>>>>>    #
>>>>>>
>>>>>> +-doc_begin="Xen does not use C and POSIX libraries:
>>>>>> +identifiers reserved by these libraries can be used safely, except
>>>>>> for those
>>>>>> +beginning with '__builtin_'."
>>>>>> +-config=MC3A2.R21.1,macros={safe, "!^__builtin_.*$"}
>>>>>> +-config=MC3A2.R21.2,declarations={safe, "!^__builtin_.*$"}
>>>>>> +-doc_end
>>>>>> +
>>>>>>    -doc_begin="or, and and xor are reserved identifiers because 
>>>>>> they
>>>>>> constitute alternate
>>>>>> -spellings for the corresponding operators (they are defined as
>>>>>> macros by iso646.h).
>>>>>> +spellings for the corresponding logical operators (as defined in
>>>>>> header 'iso646.h').
>>>>>>    However, Xen doesn't use standard library headers, so there is 
>>>>>> no
>>>>>> risk of overlap."
>>>>>>    -config=MC3A2.R21.2,reports+={safe,
>>>>>> "any_area(stmt(ref(kind(label)&&^(or|and|xor|not)$)))"}
>>>>>>    -doc_end
>>>>>> diff --git a/automation/eclair_analysis/ECLAIR/monitored.ecl b/
>>>>>> automation/eclair_analysis/ECLAIR/monitored.ecl
>>>>>> index 8351996ec8..da229a0d84 100644
>>>>>> --- a/automation/eclair_analysis/ECLAIR/monitored.ecl
>>>>>> +++ b/automation/eclair_analysis/ECLAIR/monitored.ecl
>>>>>> @@ -79,6 +79,8 @@
>>>>>>    -enable=MC3A2.R20.12
>>>>>>    -enable=MC3A2.R20.13
>>>>>>    -enable=MC3A2.R20.14
>>>>>> +-enable=MC3A2.R21.1
>>>>>> +-enable=MC3A2.R21.2
>>>>>>    -enable=MC3A2.R21.3
>>>>>>    -enable=MC3A2.R21.4
>>>>>>    -enable=MC3A2.R21.5
>>>>>> diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/
>>>>>> automation/eclair_analysis/ECLAIR/tagging.ecl
>>>>>> index 1d078d8905..3292bf751e 100644
>>>>>> --- a/automation/eclair_analysis/ECLAIR/tagging.ecl
>>>>>> +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
>>>>>> @@ -88,6 +88,8 @@ MC3A2.R20.11||
>>>>>>    MC3A2.R20.12||
>>>>>>    MC3A2.R20.13||
>>>>>>    MC3A2.R20.14||
>>>>>> +MC3A2.R21.1||
>>>>>> +MC3A2.R21.2||
>>>>>>    MC3A2.R21.3||
>>>>>>    MC3A2.R21.4||
>>>>>>    MC3A2.R21.5||
>>>>>> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
>>>>>> index fe0b1e10a2..88328eaa8a 100644
>>>>>> --- 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.
>>>>>> +
>>>>>> +   * - R21.2
>>>>>> +     - Rule 21.2 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 declaring such identifiers except for those beginning
>>>>>> with
>>>>>> +       `__builtin_` for which compilers may perform (wrong)
>>>>>> optimizations.
>>>>>> +     - Tagged as `safe` for ECLAIR.
>>>>>> +
>>>>>> +   * - R21.2
>>>>>> +     - `or`, `and` and `xor` are reserved identifiers because they
>>>>>> constitute
>>>>>> +       alternate spellings for the corresponding logical operators
>>>>>> +       (as defined in Standard Library header `\<iso646.h\>`). Xen
>>>>>> does not use
>>>>>> +       Standard library headers, so there is no risk of overlap.
>>>>>> +     - Tagged as `safe` for ECLAIR.
>>>>>> +
>>>>>>       * - R21.9
>>>>>>         - Xen does not use the `bsearch` and `qsort` functions
>>>>>> provided by the C
>>>>>>           Standard Library, but provides in source form its own
>>>>>> implementation,
>>>>>> --
>>>>>> 2.47.0
>>>>>
>>>>> Hello All!
>>>>>
>>>>> I tried to play with Rule 21.1 deviations.
>>>>>
>>>>> After applying the following configurations:
>>>>>
>>>>> -config=MC3A2.R21.1,macros+={safe, "^offsetof$ || ^(is|to)[a-z]+$ ||
>>>>> name(NULL) || name(bool) || name(true) || name(false)"}
>>>>> -config=MC3A2.R21.1,macros+={safe,
>>>>> "loc(file(^xen/include/xen/inttypes\\.h$))"}
>>>>> -config=MC3A2.R21.1,macros+={safe, "loc(file(^xen/include/xen/types\
>>>>> \.h$))"}
>>>>> -config=MC3A2.R21.1,macros+={safe, "^str[a-z]+$ || ^(v)?sprintf$ ||
>>>>> ^va_[a-z]+$"}
>>>>
>>>> Can you spell these out in words? I can only vaguely interpret these
>>>> Eclair
>>>> patterns, sorry.
>>> Yes, sure.
>>>
>>> That means to deviate the following macros:
>>> - offsetof
>>> - begin with either ‘is’ or ‘to’ followed by a lowercase letters
>>> (islower, isdigit, tolower, toupper, etc.)
>>> - NULL
>>> - bool
>>> - true
>>> - false
>>> - all PRI/SCN macros for printing/scanning format specifiers from 
>>> header
>>> file xen/include/xen/inttypes.h
>>> - all macros from header file xen/include/xen/types.h (limits:
>>> UINT8_MAX, INT_MAX, LONG_MIN, etc.)
>>> - begin with 'str' followed by a lowercase letters (string functions)
>>> - sprintf/vsprintf
>>> - begin with 'va_' followed by a lowercase letters (va_copy, va_start,
>>> va_end, va_arg)
>>>
>>>>
>>>>> Eclair showed 699 remaining violations.
>>>>> All of them were related to names beginning with an underscore (_).
>>>>>
>>>>> It's possible to resolve the rest of them with help of (all, except 
>>>>> for
>>>>> those beginning with '__builtin_' and '__x86_64__'):
>>>>>
>>>>> -config=MC3A2.R21.1,macros+={safe, "^_.*$ && !^__builtin_.*$ &&
>>>>> !^__x86_64__$"}
>>>>>
>>>>> Probably, the exception list can be extended.
>>>>>
>>>>> Jan,
>>>>> I know you don't want to disallow "_all_" such reserved identifiers.
>>>>> But how to deal with that?
>>>>
>>>> How do I not want this? I've been arguing for years that we should
>>>> respect
>>>> the reserved name spaces. (Did you perhaps mean "... you don't want 
>>>> to
>>>> deviate ..."?) There are exceptions, yes, e.g. ...
>>>>
>>> Yes, I meant about deviations. Sorry.
>>>
>>>>> Try to cover all macros? Like this, for example (I assume that there 
>>>>> are
>>>>> no such reserved macros):
>>>>> -config=MC3A2.R21.1,macros+={safe, "^.*XEN.*$ || ^.*HYPERVISOR.*$"}
>>>>
>>>> ... anything we may have (wrongly) introduced into the public 
>>>> headers. We
>>>> can't very well change naming there.
>>> Looks like the only way is to deviate all macros (that are currently
>>> used in Xen), tag rule as "clean" and prohibit using reserved names in
>>> the future.
>>>
>>> Any suggestions?
>>>
>>> Dmytro
>>
>> BTW, not all violations are in public headers.
>> Probably, they could be fixed in code.
>> But the number of them is huge...
>>
> 
> This is precisely the issue I was pointing out when you offered to 
> respin this patch. Yes, Xen could fix those rather than deviate, but the 
> sheer number of violations makes this in my opinion unfeasible.
Time for a sed script?  Only half-joking.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]