| Message ID | b89e106649e3d0ecb41baadb49dc09c54b7563ec.1718873635.git.alessandro.zucchelli@bugseng.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | automation/eclair_analysis: deviate and|or|xor for MISRA C Rule 21.2 | expand |
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>
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
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(+)