[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fb744859-ba2a-41c9-bcfa-4ea1cb8c036a@sirena.org.uk>
Date: Thu, 21 Mar 2024 11:15:18 +0000
From: Mark Brown <broonie@...nel.org>
To: Barry Song <21cnbao@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Stephen Rothwell <sfr@...b.auug.org.au>, corbet@....net,
workflows@...r.kernel.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, Barry Song <v-songbaohua@...o.com>,
Chris Zankel <chris@...kel.net>,
Huacai Chen <chenhuacai@...ngson.cn>,
Herbert Xu <herbert@...dor.apana.org.au>,
Guenter Roeck <linux@...ck-us.net>,
Max Filippov <jcmvbkbc@...il.com>
Subject: Re: [PATCH] Documentation: coding-style: ask function-like macros to
evaluate parameters
On Thu, Mar 21, 2024 at 07:48:36AM +1300, Barry Song wrote:
> On Thu, Mar 21, 2024 at 4:49 AM Andrew Morton <akpm@...ux-foundation.org> wrote:
> > Stronger than that please. Just tell people not to use macros in such
> > situations. Always code it in C.
> While I appreciate the consistency of always using "static inline"
> instead of macros,
> I've noticed numerous instances of (void) macros throughout the kernel.
...
> I'm uncertain whether people would find it disconcerting if they completely
> deviate from the current approach.
> If you believe it won't pose an issue, I can proceed with v3 to eliminate
> the first option, casting to (void).
It might be worth adding a note somewhere in the file that talks about
how the coding style document is convering the current state of the art
but some files might older and not following the current style. This
isn't going to be the only thing where there'll be issues like this.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists