Received-SPF: pass (google.com: domain of linux-kernel+bounces-110646-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <20240320001656.10075-1-21cnbao@gmail.com> <20240320124207.0c127947@canb.auug.org.au>
 <CAGsJ_4zpXwVEhsdffoZVBVWiwT4Lw2qEMrW-X92ib=kv=9Yx9g@mail.gmail.com>
 <20240320084919.8e18adb418347feed6bfc8ae@linux-foundation.org>
 <CAGsJ_4y+1HovQ52HPis8NBDqp4-fiGRwehX+NH0New0HoEU5GQ@mail.gmail.com> <fb744859-ba2a-41c9-bcfa-4ea1cb8c036a@sirena.org.uk>
In-Reply-To: <fb744859-ba2a-41c9-bcfa-4ea1cb8c036a@sirena.org.uk>
From: Barry Song <21cnbao@gmail.com>
Date: Fri, 22 Mar 2024 09:29:39 +1300
Message-ID: <CAGsJ_4xSj7i-3Y+ALBh8coa=-6CGx19Zh=CPFGJq9hv4MDZZ=Q@mail.gmail.com>
Subject: Re: [PATCH] Documentation: coding-style: ask function-like macros to
 evaluate parameters
To: Mark Brown <broonie@kernel.org>, Andrew Morton <akpm@linux-foundation.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, corbet@lwn.net, workflows@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	Barry Song <v-songbaohua@oppo.com>, Chris Zankel <chris@zankel.net>, 
	Huacai Chen <chenhuacai@loongson.cn>, Herbert Xu <herbert@gondor.apana.org.au>, 
	Guenter Roeck <linux@roeck-us.net>, Max Filippov <jcmvbkbc@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 22, 2024 at 12:15=E2=80=AFAM Mark Brown <broonie@kernel.org> wr=
ote:
>
> On Thu, Mar 21, 2024 at 07:48:36AM +1300, Barry Song wrote:
> > On Thu, Mar 21, 2024 at 4:49=E2=80=AFAM Andrew Morton <akpm@linux-found=
ation.org> wrote:
>
> > > Stronger than that please.  Just tell people not to use macros in suc=
h
> > > 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 comple=
tely
> > deviate from the current approach.
>
> > If you believe it won't pose an issue, I can proceed with v3 to elimina=
te
> > 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.


I'm not entirely sure where to add the comment, but at least I can address
this specific case by rewriting it as follows:

diff --git a/Documentation/process/coding-style.rst
b/Documentation/process/coding-style.rst
index 9c7cf7347394..791d333a57fd 100644
--- a/Documentation/process/coding-style.rst
+++ b/Documentation/process/coding-style.rst
@@ -827,6 +827,22 @@ Macros with multiple statements should be
enclosed in a do - while block:
                                do_this(b, c);          \
                } while (0)

+Function-like macros with unused parameters should be replaced by static
+inline functions to avoid the issue of unused variables:
+
+.. code-block:: c
+
+       static inline void fun(struct foo *foo)
+       {
+       }
+
+For historical reasons, many files still use the cast to (void) to evaluat=
e
+parameters, but this method is not recommended:
+
+.. code-block:: c
+
+       #define macrofun(foo) do { (void) (foo); } while (0)
+
 Things to avoid when using macros:

 1) macros that affect control flow:


Mark, Andrew,
Does it make sense to you?

Thanks
Barry