[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <71d4279ca9524b2382059cd2f723e20e@AcuMS.aculab.com>
Date: Sat, 6 May 2023 15:45:54 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Linus Torvalds' <torvalds@...ux-foundation.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
CC: Andrew Morton <akpm@...ux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Jens Axboe <axboe@...nel.dk>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>
Subject: RE: [RFC PATCH 12/13] blk-mq.h: Fix parentheses around macro
parameter use
From: Linus Torvalds
> Sent: 05 May 2023 20:55
....
> > The other exception I would add is when a parameter is used as an
> > lvalue, as:
> >
> > #define m(x) do { x = 2; } while (0)
>
> I really don't understand why you think '=' is so special. It's very
> much not special.
>
> It happens to have the lowest precedence, sure, but the keyword is "happens".
And consider what happens if you try:
m(a ? b : c)
Personally I'd avoid using parameters as lvalues if at all possible.
It is much better to have:
#define m(x) do { *(x) = 2; } while (0)
and require the caller do m(&foo) to make it obvious the value is changed.
(Apart from loop definitions...)
Things like the C++ 'int &arg' make it hard to scan read/search
code for places where variables get changed.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists