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

[Nicola Vetrini <nicola.vetrini@bugseng.com>]

On 2024-03-05 11:26, Jan Beulich wrote:
> 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.
> 

Sure.

>> 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

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)