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
