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

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

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)