On 25/02/2026 4:34 pm, Nicola Vetrini wrote: > 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= > [...]
Oh ok. I'll make it match what was agreed then. Thanks, ~Andrew
