linux-kernel - Re: [PATCH] Documentation: coding-style: ask function-like macros to evaluate parameters

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAGsJ_4xSj7i-3Y+ALBh8coa=-6CGx19Zh=CPFGJq9hv4MDZZ=Q@mail.gmail.com>
Date: Fri, 22 Mar 2024 09:29:39 +1300
From: Barry Song <21cnbao@...il.com>
To: Mark Brown <broonie@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>
Cc: 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 Fri, Mar 22, 2024 at 12:15 AM Mark Brown <broonie@...nel.org> wrote:
>
> 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.


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 evaluate
+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