Re: [XEN PATCH][for-4.19 v2] xen: Add SAF deviations for MISRA C:2012 Rule 7.1

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

On 23/10/2023 10:47, Jan Beulich wrote:
> On 23.10.2023 10:44, Nicola Vetrini wrote:
> > > > > > 3. an use of MASK_EXTR() in x86/hvm/svm/emulate.c appears, with
> > > > > > octal
> > > > > >     constants in the expansion. This will be deviated;
> > > > > This is what I'm concerned of: How do you know up front whether 
> > > > > such
> > > > > new
> > > > > uses want deviating?
> > > > I understand you concern now. I can argue that all the macros in 
> > > > that
> > > > table have indeed
> > > > an octal constant in their definition (0 is explicitly allowed by
> > > > MISRA).
> > > > This is also specified in the comment above the INSTR_ENC macro
> > > > definition, therefore any
> > > > new addition should have an octal the second argument to INSTR_ENC.
> > > Right, and I previously indicated I agree as far as INSTR_ENC() goes.
> > > What we appear to continue to disagree about is MASK_EXTR().
> > Yeah, sorry. What about
> >
> > if ( modrm_mod       == MASK_EXTR(instr_modrm, 0300) && /* octal-ok */
> >       (modrm_reg & 7) == MASK_EXTR(instr_modrm, 0070) && /* octal-ok 
> > */
> >       (modrm_rm  & 7) == MASK_EXTR(instr_modrm, 0007) )  /* octal-ok 
> > */
> >              return emul_len;
> >
> > It does not really fit in the SAF framework, because the deviation is
> > still done with a
> > configuration, but at least it gives some clear indication on how to
> > introduce an octal
> > constant in this file.
> Well, I don't mind the comment, but is the config change then going to
> also match (part of) the comment, i.e. key off of not just MASK_EXTR()?
>
> Jan
Yes, I added that to my reply.

--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)