[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <693ce771113d49da92235a0f6d2e395f@AcuMS.aculab.com>
Date: Wed, 8 Feb 2023 12:29:38 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Peter Zijlstra' <peterz@...radead.org>,
"x86@...nel.org" <x86@...nel.org>, Borislav Petkov <bp@...en8.de>
CC: Masami Hiramatsu <mhiramat@...nel.org>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Andrew Cooper <Andrew.Cooper3@...rix.com>,
Josh Poimboeuf <jpoimboe@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] x86/alternative: Support relocations in alternatives
From: Peter Zijlstra
> Sent: 06 February 2023 15:06
...
> +#define apply_reloc_n(n_, p_, d_) \
> + do { \
> + s32 v = *(s##n_ *)(p_); \
You've added '_' suffixes to the parameters.
But these only refer to the body of the #define
so are never a problem.
OTOH the local 'v' will cause confusion if one of the
actual parameters is 'v'.
Which is why it is common to prefix locals with '_'.
(Which doesn't help with recursive expansions.)
Since this is only actually expended in the one .c file
it is unlikely to cause a problem.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists