Re: [PATCH 11/12] xen: Bracket uses of macro parameters

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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 <andrew.cooper3@xxxxxxxxxx>
>>>
>>> Reviewed-by: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
>>
>> 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