Re: [PATCH v1] misra: add deviation for rules 21.1 and 21.2

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

On 2025-04-25 10:07, Jan Beulich wrote:
> 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.
Hi Jan,

that is true, even if unlikely: one approach could be to avoid deviating 
predefined macros for all CUs as -nostdinc and -fno-builtins should take 
care of the rest; this kind of deviation is not currently possible in 
ECLAIR, but it might be in the future. I think this could be 
accomplished also via some gcc trickery on each CU, though I'm not sure 
how valued that is for Xen.
--
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253