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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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