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). 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
My gut feeling tells me that probably this is what we want but I'd
rather first understand exactly what you meant above
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
