On 2026-02-25 17:05, Andrew Cooper wrote:
On 20/02/2026 10:45 pm, Nicola Vetrini wrote:
On 2026-02-20 22:46, Andrew Cooper wrote:
Fixing Rule 20.7 violations.
No functional change.
Signed-off-by: Andrew Cooper <[email protected]>
Reviewed-by: Nicola Vetrini <[email protected]>
Thanks.
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 7446533c8cfb..63473925cafb 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -664,9 +664,10 @@ static inline int
livepatch_check_expectations(const struct payload *payload)
const struct livepatch_elf_sec *__sec =
livepatch_elf_sec_by_name(elf, section_name); \
if ( !__sec
)
\
break;
\
- if ( !section_ok(elf, __sec, sizeof(*hook)) ||
__sec->sec->sh_size != sizeof(*hook) ) \
+ if ( !section_ok(elf, __sec, sizeof(*(hook)))
|| \
+ __sec->sec->sh_size != sizeof(*(hook))
) \
return
-EINVAL;
\
- hook =
__sec->addr;
\
+ (hook) =
__sec->addr;
\
This is not strictly needed, if not for consistency.
That explains why my first try didn't succeed. But, why is it that
only
MISRA only cares about bracketing for rvalues, not lvalues ?
It was actually asked by Xen maintainers to introduce this special case
on the grounds that it is extremely unlikely to result in an operator
precedence mishap that leads to incorrect expansion. See below:
-doc_begin="Code violating Rule 20.7 is safe when macro parameters are
used: (1)
as function arguments; (2) as macro arguments; (3) as array indices; (4)
as lhs
in assignments; (5) as initializers, possibly designated, in initalizer
lists;
(6) as the constant expression in a switch clause label."
-config=MC3A2.R20.7,expansion_context=
[...]
--
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253
