[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [XEN PATCH][for-4.19 v2] xen: Add SAF deviations for MISRA C:2012 Rule 7.1
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
- Date: Mon, 23 Oct 2023 10:44:16 +0200
- Cc: sstabellini@xxxxxxxxxx, michal.orzel@xxxxxxx, xenia.ragiadakou@xxxxxxx, ayan.kumar.halder@xxxxxxx, consulting@xxxxxxxxxxx, andrew.cooper3@xxxxxxxxxx, roger.pau@xxxxxxxxxx, Simone Ballarin <simone.ballarin@xxxxxxxxxxx>, Doug Goldstein <cardoe@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Mon, 23 Oct 2023 08:44:25 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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.
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
|