Re: [PATCH] automation/eclair_analysis: deviate and|or|xor for MISRA C Rule 21.2

[Jan Beulich <jbeulich@xxxxxxxx>]

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