Re: [XEN PATCH 04/10] xen/public: address violations of MISRA C Rule 20.7

[Jan Beulich <jbeulich@xxxxxxxx>]

On 05.03.2024 11:21, Nicola Vetrini wrote:
> On 2024-02-29 23:49, Stefano Stabellini wrote:
>> On Thu, 29 Feb 2024, 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.
>>
>> I don't understand what you mean. Maybe a couple of trivial examples
>> would help.
>>
>>
>>> 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, ...}"
>>
> 
> Sorry for the late reply. This is the current state:
> 
> #define N(x) somestruct var = {..., x, ...}; // <- not deviated, 
> violation here
> #define M(x) N(x) // <- deviated, no violation here
> 
> ...
> 
> M(0xff);
> 
> The violation is resolved by {..., (x), ...} or by saying that when "x" 
> is a whole expression in its fully expanded form, then we allow it not 
> to be needlessly parenthesized, as Jan requested (unless I misunderstood 
> his reply).

Well, the thing I continue to have trouble with is "fully expanded form".
That's not the criteria I'd like to see applied. To me all depends on how
the macro is written, not what uses of the macro expand to.

> In that case, the only this that would still give a 
> violation in the above setting is questionable patterns such as
> 
> #define Q(x) x, x

Right.

#define Q(x) (x, x)

ought to be okay though, rule-wise, no matter that it's questionable too.

Jan