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] [thread-next>] [day] [month] [year] [list]
Message-ID: <a2cf1f09-83d7-402b-94c1-88feec10a513@icloud.com>
Date: Sat, 22 Feb 2025 18:51:17 +0800
From: Zijun Hu <zijun_hu@...oud.com>
To: Johannes Berg <johannes@...solutions.net>,
 Stephen Hemminger <stephen@...workplumber.org>,
 Zijun Hu <quic_zijuhu@...cinc.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Will Deacon <will@...nel.org>, "Aneesh Kumar K.V" <aneesh.kumar@...nel.org>,
 Andrew Morton <akpm@...ux-foundation.org>, Nick Piggin <npiggin@...il.com>,
 Peter Zijlstra <peterz@...radead.org>, Arnd Bergmann <arnd@...db.de>,
 Thomas Gleixner <tglx@...utronix.de>,
 Herbert Xu <herbert@...dor.apana.org.au>,
 "David S. Miller" <davem@...emloft.net>,
 "Rafael J. Wysocki" <rafael@...nel.org>, Danilo Krummrich <dakr@...nel.org>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
 Jamal Hadi Salim <jhs@...atatu.com>, Cong Wang <xiyou.wangcong@...il.com>,
 Jiri Pirko <jiri@...nulli.us>, Jason Gunthorpe <jgg@...pe.ca>,
 Leon Romanovsky <leon@...nel.org>, Linus Walleij <linus.walleij@...aro.org>,
 Bartosz Golaszewski <brgl@...ev.pl>, Lee Jones <lee@...nel.org>,
 Thomas Graf <tgraf@...g.ch>, Christoph Hellwig <hch@....de>,
 Marek Szyprowski <m.szyprowski@...sung.com>,
 Robin Murphy <robin.murphy@....com>,
 Miquel Raynal <miquel.raynal@...tlin.com>,
 Richard Weinberger <richard@....at>, Vignesh Raghavendra <vigneshr@...com>,
 linux-arch@...r.kernel.org, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
 netdev@...r.kernel.org, linux-wireless@...r.kernel.org,
 linux-rdma@...r.kernel.org, linux-gpio@...r.kernel.org,
 linux-pm@...r.kernel.org, iommu@...ts.linux.dev,
 linux-mtd@...ts.infradead.org
Subject: Re: [PATCH *-next 00/18] Remove weird and needless 'return' for void
 APIs

On 2025/2/22 03:36, Johannes Berg wrote:
> On Fri, 2025-02-21 at 11:00 -0800, Stephen Hemminger wrote:
>> Is this something that could be done with a coccinelle script?
>>
> Almost enough to do this:
> 
> @@
> identifier fn;
> expression E;
> @@
> void fn(...)
> {
> ...
> -return
> E;
> }
> 
> 
> It takes a long time to run though, and does some wrong things as well:
> if the return is in the middle of the function, it still matches and
> removes it erroneously.

if return is in the middle, we may need to convert the return statement
in to two statement as [PATCH 18/18] does:
https://lore.kernel.org/all/20250221-rmv_return-v1-18-cc8dff275827@quicinc.com/

namely, Convert  "return func(...);" to "func(...); return;"

C spec such as C17 have this description about return
statement:
6.8.6.4:
A return statement with an expression shall not appear in a function
whose return type is void. A return statement without an expression
shall only appear in a function whose return type is void.


so, do we need to treat "return void function in void function" as
bad code style and make coccinelle script check this bad usage?






Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ