diff mbox series

[XEN,3/4] x86_64/uaccess: address violations of MISRA C Rule 20.7

Message ID b131427dc03c4b89141bab7648523b81bf5186a6.1715757982.git.nicola.vetrini@bugseng.com (mailing list archive)
State New
Headers show
Series address violations of MISRA C Rule 20.7 | expand

Commit Message

Nicola Vetrini May 15, 2024, 7:34 a.m. UTC
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.

xlat_malloc_init is touched for consistency, despite the construct
being already deviated.

No functional change.

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
---
 xen/arch/x86/include/asm/x86_64/uaccess.h | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

Comments

Stefano Stabellini May 15, 2024, 11:19 p.m. UTC | #1
On Wed, 15 May 2024, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
> 
> xlat_malloc_init is touched for consistency, despite the construct
> being already deviated.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Jan Beulich May 21, 2024, 11:27 a.m. UTC | #2
On 16.05.2024 01:19, Stefano Stabellini wrote:
> On Wed, 15 May 2024, Nicola Vetrini wrote:
>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
>> of macro parameters shall be enclosed in parentheses". Therefore, some
>> macro definitions should gain additional parentheses to ensure that all
>> current and future users will be safe with respect to expansions that
>> can possibly alter the semantics of the passed-in macro parameter.
>>
>> xlat_malloc_init is touched for consistency, despite the construct
>> being already deviated.
>>
>> No functional change.
>>
>> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
> 
> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

Acked-by: Jan Beulich <jbeulich@suse.com>
diff mbox series

Patch

diff --git a/xen/arch/x86/include/asm/x86_64/uaccess.h b/xen/arch/x86/include/asm/x86_64/uaccess.h
index ba79f950fba9..c6fa3fd381bc 100644
--- a/xen/arch/x86/include/asm/x86_64/uaccess.h
+++ b/xen/arch/x86/include/asm/x86_64/uaccess.h
@@ -26,15 +26,16 @@  void free_compat_arg_xlat(struct vcpu *v);
 #define xlat_page_start ((unsigned long)COMPAT_ARG_XLAT_VIRT_BASE)
 #define xlat_page_size  COMPAT_ARG_XLAT_SIZE
 #define xlat_page_left_size(xlat_page_current) \
-    (xlat_page_start + xlat_page_size - xlat_page_current)
+    (xlat_page_start + xlat_page_size - (xlat_page_current))
 
 #define xlat_malloc_init(xlat_page_current)    do { \
-    xlat_page_current = xlat_page_start; \
+    (xlat_page_current) = xlat_page_start; \
 } while (0)
 
 extern void *xlat_malloc(unsigned long *xlat_page_current, size_t size);
 
-#define xlat_malloc_array(_p, _t, _c) ((_t *) xlat_malloc(&_p, sizeof(_t) * _c))
+#define xlat_malloc_array(_p, _t, _c) ((_t *) xlat_malloc(&(_p), \
+                                                          sizeof(_t) * (_c)))
 
 /*
  * Valid if in +ve half of 48-bit address space, or above Xen-reserved area.