[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v1] misra: add deviation for rules 21.1 and 21.2
On 23.04.2025 19:54, victorm.lira@xxxxxxx wrote: > From: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx> > > MISRA C Rules 21.1 ("#define and #undef shall not be used on a > reserved identifier or reserved macro name") and R21.2 ("A reserved > identifier or reserved macro name shall not be declared") violations > are not problematic for Xen, as it does not use the C or POSIX > libraries. > > Xen uses -fno-builtin and -nostdinc to ensure this, but there are still > __builtin_* functions from the compiler that are available so > a deviation is formulated for all identifiers not starting with > "__builtin_". > > The missing text of a deviation for Rule 21.2 is added to > docs/misra/deviations.rst. > > To avoid regressions, tag both rules as clean and add them to the > monitored set. > > Signed-off-by: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx> > Signed-off-by: Federico Serafini <federico.serafini@xxxxxxxxxxx> > Signed-off-by: Victor Lira <victorm.lira@xxxxxxx> While the rule is in the library section, ... > --- a/docs/misra/deviations.rst > +++ b/docs/misra/deviations.rst > @@ -587,7 +587,31 @@ Deviations related to MISRA C:2012 Rules: > construct is deviated only in Translation Units that present a > violation > of the Rule due to uses of this macro. > - Tagged as `deliberate` for ECLAIR. > - > + > + * - R21.1 > + - Rule 21.1 reports identifiers reserved for the C and POSIX standard > + libraries. Xen does not use such libraries and all translation units > + are compiled with option '-nostdinc', therefore there is no reason to > + avoid to use `#define` or `#undef` on such identifiers except for > those > + beginning with `__builtin_` for which compilers may perform (wrong) > + optimizations. > + - Tagged as `safe` for ECLAIR. ... I'd like to ask that it be explicitly clarified here that it's solely the library (and not e.g. the compiler itself) that are of concern here. If so, I expect there's another rule dealing with the remaining concerns. Then, however, I consider the rule wording insufficient (as leaving an ambiguity). Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |