On 29.02.2024 17:49, Nicola Vetrini wrote:
> On 2024-02-29 17:40, Jan Beulich wrote:
>> On 29.02.2024 16:27, Nicola Vetrini wrote:
>>> --- a/xen/include/public/xen.h
>>> +++ b/xen/include/public/xen.h
>>> @@ -988,7 +988,7 @@ typedef struct {
>>> ((b) >> 8) & 0xFF, ((b) >> 0) & 0xFF,
>>> \
>>> ((c) >> 8) & 0xFF, ((c) >> 0) & 0xFF,
>>> \
>>> ((d) >> 8) & 0xFF, ((d) >> 0) & 0xFF,
>>> \
>>> - e1, e2, e3, e4, e5, e6}}
>>> + (e1), (e2), (e3), (e4), (e5), (e6)}}
>>
>> Why? Wasn't it agreed already that long macro arguments passed on
>> (no matter whether to a function, a macro, or like used here) don't
>> need parenthesizing?
>>
>
> That applies to all outermost macro invocations, but not to the
> innermost one. If you want also aggregate initalizers to be deviated,
> that could be done (provided that the macro arg is not included in some
> expression, such as "{..., e1 + 1, ...}"
Sure, this obviously needs to be "{..., (e1) + 1, ...}" then. But yes,
the full scope of the underlying pattern ought to be excluded from
needing (pointless) parentheses added. Even in a plain comma expression
you don't need them - to pass in a comma expression the invocation site
of such a macro would then need to parenthesize the respective operand
(or else it would be two separate operands).
The one case we're leaving aside here anyway is use of odd things like
#define M a, b
and then passing M into another macro.
Jan
