Rule 21.2 reports identifiers reserved for the C and POSIX standard
libraries: or, and, not and xor are reserved identifiers because they
constitute alternate spellings for the corresponding operators (they are
defined as macros by iso646.h); however Xen doesn't use standard library
headers, so there is no risk of overlap.

This addresses violations arising from x86_emulate/x86_emulate.c, where
label statements named as or, and and xor appear.

No functional change.

Signed-off-by: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
---
Changes from v1:
Added deviation for 'not' identifier.
Added explanation of where these identifiers are defined, specifically in the
'iso646.h' file of the Standard Library.
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 069519e380..14c7afb39e 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -501,7 +501,7 @@ still remain available."
 -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).
 However, Xen doesn't use standard library headers, so there is no risk of overlap."
--config=MC3R1.R21.2,reports+={safe, "any_area(stmt(ref(kind(label)&&^(or|and|xor)$)))"}
+-config=MC3R1.R21.2,reports+={safe, "any_area(stmt(ref(kind(label)&&^(or|and|xor|not)$)))"}
 -doc_end
 
 -doc_begin="Xen does not use the functions provided by the Standard Library, but
-- 
2.34.1

On Fri, 21 Jun 2024, Alessandro Zucchelli wrote:
> Rule 21.2 reports identifiers reserved for the C and POSIX standard
> libraries: or, and, not and xor are reserved identifiers because they
> constitute alternate spellings for the corresponding operators (they are
> defined as macros by iso646.h); however Xen doesn't use standard library
> headers, so there is no risk of overlap.
> 
> This addresses violations arising from x86_emulate/x86_emulate.c, where
> label statements named as or, and and xor appear.
> 
> No functional change.
> 
> Signed-off-by: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
> Acked-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
> Changes from v1:
> Added deviation for 'not' identifier.
> Added explanation of where these identifiers are defined, specifically in the
> 'iso646.h' file of the Standard Library.
> ---
>  automation/eclair_analysis/ECLAIR/deviations.ecl | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
> index 069519e380..14c7afb39e 100644
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -501,7 +501,7 @@ still remain available."
>  -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).
>  However, Xen doesn't use standard library headers, so there is no risk of overlap."
> --config=MC3R1.R21.2,reports+={safe, "any_area(stmt(ref(kind(label)&&^(or|and|xor)$)))"}
> +-config=MC3R1.R21.2,reports+={safe, "any_area(stmt(ref(kind(label)&&^(or|and|xor|not)$)))"}
>  -doc_end

It looks like this patch relies on the previous version to be applied?
Maybe you forgot to squash your changes with your previous patch?