[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 24.04.2025 23:45, Stefano Stabellini wrote: > On Thu, 24 Apr 2025, Jan Beulich wrote: >> 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. > > The language can be clarified: > > - 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 C and POSIX standard libraries > identifiers except for those beginning with `__builtin_` for which > compilers may perform (wrong) optimizations. Which makes it more apparent that there is a gap: What about e.g. __x86_64__? That falls within what the rules cover, is not a C or POSIX standard library identifier, yet very clearly must not be fiddled with. Whereas the text above deviates it. Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |