Received-SPF: pass (google.com: domain of linux-kernel+bounces-109934-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Thu, 21 Mar 2024 11:15:18 +0000
From: Mark Brown <broonie@kernel.org>
To: Barry Song <21cnbao@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	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>
Subject: Re: [PATCH] Documentation: coding-style: ask function-like macros to
 evaluate parameters
Message-ID: <fb744859-ba2a-41c9-bcfa-4ea1cb8c036a@sirena.org.uk>
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>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="TAcSmNRE4p6o+wUy"
Content-Disposition: inline
In-Reply-To: <CAGsJ_4y+1HovQ52HPis8NBDqp4-fiGRwehX+NH0New0HoEU5GQ@mail.gmail.com>


--TAcSmNRE4p6o+wUy
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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-foundat=
ion.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.

=2E..

> I'm uncertain whether people would find it disconcerting if they complete=
ly
> 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.

--TAcSmNRE4p6o+wUy
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmX8FsYACgkQJNaLcl1U
h9AMfwf9HeqraXnXYAw78tCMuY0c1TL2y4BWC0+oKGPXHbxTF9LV17xmodaBRTBp
LglMvk9nR02owGQSdhqz3csnWWQp2/Qg47UkSNOl//Vplk5wCBujNtA0+ojtD9oD
zf0VRykp1ifuYu5TMA12dAGZlJlYuKbjzWIlGRZiAJgCxsOTnfMSrzYHVjiQB7cH
gnUBrUCHyGCFikMLUOdPPERN+XrUxClfIQiv80gF7BM5iDoD8F1bqgNSbl/+7xpE
a8V5Kf98YMGCeGhCfc7hbnqJS58027LhgY5c/JbuavBZl8kL+HvkoMtdjyK0ZXoU
8VjGqD2egSNvzVZjxxI20l49UlaCoA==
=ic4b
-----END PGP SIGNATURE-----

--TAcSmNRE4p6o+wUy--