Rule 21.2 reports identifiers reserved for the C and POSIX standard
libraries: or, and and xor are reserved identifiers because they constitute
alternate spellings for the corresponding operators; 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>
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 9fa9a7f01c..069519e380 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -498,6 +498,12 @@ still remain available."
 -config=MC3R1.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.
+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)$)))"}
+-doc_end
+
 -doc_begin="Xen does not use the functions provided by the Standard Library, but
 implements a set of functions that share the same names as their Standard Library equivalent.
 The implementation of these functions is available in source form, so the undefined, unspecified
-- 
2.34.1

On 20.06.2024 11:07, Alessandro Zucchelli wrote:
> Rule 21.2 reports identifiers reserved for the C and POSIX standard
> libraries: or, and and xor are reserved identifiers because they constitute
> alternate spellings for the corresponding operators; however Xen doesn't
> use standard library headers, so there is no risk of overlap.

This is iso646.h aiui, which imo would be good to mention here, just
to avoid people needing to go hunt for where this is coming from.

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

So a deviation purely by present uses, even ...

> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -498,6 +498,12 @@ still remain available."
>  -config=MC3R1.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.
> +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)$)))"}
> +-doc_end

... constrained to just labels. Why would we do that? Why can't we deviate
them all (or at least all that are plausible to potentially use somewhere,
which imo would include at least "not" as well), and no matter what
syntactical element they would be used as?

Besides, just as a remark: Specifically when used as label names, there's
no risk at all, I'm inclined to say. If iso646.h existed in Xen and was
included in such a source file, the compiler would choke on the result.

Jan

On Thu, 20 Jun 2024, Jan Beulich wrote:
> On 20.06.2024 11:07, Alessandro Zucchelli wrote:
> > Rule 21.2 reports identifiers reserved for the C and POSIX standard
> > libraries: or, and and xor are reserved identifiers because they constitute
> > alternate spellings for the corresponding operators; however Xen doesn't
> > use standard library headers, so there is no risk of overlap.
> 
> This is iso646.h aiui, which imo would be good to mention here, just
> to avoid people needing to go hunt for where this is coming from.
> 
> > This addresses violations arising from x86_emulate/x86_emulate.c, where
> > label statements named as or, and and xor appear.
> 
> So a deviation purely by present uses, even ...
> 
> > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> > @@ -498,6 +498,12 @@ still remain available."
> >  -config=MC3R1.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.
> > +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)$)))"}
> > +-doc_end
> 
> ... constrained to just labels. Why would we do that? Why can't we deviate
> them all (or at least all that are plausible to potentially use somewhere,
> which imo would include at least "not" as well), and no matter what
> syntactical element they would be used as?
> 
> Besides, just as a remark: Specifically when used as label names, there's
> no risk at all, I'm inclined to say. If iso646.h existed in Xen and was
> included in such a source file, the compiler would choke on the result.

I agree with Jan with adding "not" and deviate everywhere, but I would
only deviate for label names. That's because I agree with Jan that when
used as label names there is no risk. However, in other uses it is less
clear and I'd prefer to avoid.

Looking at this patch, it is already applying not just to x86_emulate but
everywhere. So the only improvement would be to add "not" to the list:
or|and|xor|not

I consider it nice-to-have rather than must-have, so:

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