From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id CC2E3C19F2E for ; Thu, 27 Feb 2025 13:04:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 32EA66B0085; Thu, 27 Feb 2025 08:04:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2DEA36B008A; Thu, 27 Feb 2025 08:04:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A6836B008C; Thu, 27 Feb 2025 08:04:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 02AB86B0085 for ; Thu, 27 Feb 2025 08:04:20 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 58BC71415F0 for ; Thu, 27 Feb 2025 13:04:20 +0000 (UTC) X-FDA: 83165743080.22.962E7C4 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf04.hostedemail.com (Postfix) with ESMTP id D02D540039 for ; Thu, 27 Feb 2025 13:04:10 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Dpw3udR3; spf=none (imf04.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=peterz@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740661455; a=rsa-sha256; cv=none; b=tY9hXe8uXSSOck4sBWVFufOx3v2Gyt/P92DgxMGR2r7ngTNJPSK4SbqzmNQmlVYdJI3+8T vQiK/EaMl+7AnhHf7cMQ5yUHtrq7bxnzg3kzLtBI5EHrSAVYqx33QmLyMncxb83417uqc4 9kgyBHbI1JvsYL0fV+s4Sjkz8RcrBPs= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Dpw3udR3; spf=none (imf04.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=peterz@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740661455; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=C4NTJOJ3dCAJ9+vpvzEprQrWJrpsHSJFBRqUQ8todYw=; b=zM9YUABjLzQdCHPt2Xcp1OgFuwLL61ibxZjAvKBHApdsCybMGKAJRFyZeBTnQ0foCA3c90 QFhsVPb+Pvvl0OBUpRmZvUm+ZQNR8E0bYNhE8Pw5AxgA11oaF3ToEMhxFX8kZE9oboTRxP h1xyO0SxXIoSyvM0elW3ku5FD56AU4k= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=C4NTJOJ3dCAJ9+vpvzEprQrWJrpsHSJFBRqUQ8todYw=; b=Dpw3udR3BJAFq9SyV4WrEEtnAj 4AK/f2BJmM2iCspBbFHcvyAYokish3HnL+MnOj7JlEsRpxTpwaGNuOZ0GjF1xl2kJOx4qt3J2ahuW az6fb102wILROrGzFvXwJPaH58zNpMOOcrCBc343TieQO3/CDGnn7X1+s/6kO95pgHKXAnEejIoZr eB7TVgWCB6dlZRGlAflwAymbuHq47SCX9B61CP43qWtZ2O6ijiX7nvvVtATjJJOXC5cOJJTTKtd0a 0oXIb31u03yt/F+rw+NDupYNgVgy0IBHz3v3ZGkJAqcax4tYjHYegxiTUmQ4/XbT5eUfHjXU340Lp d0XLYfiw==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux)) id 1tndYL-0000000Hb1D-0gW6; Thu, 27 Feb 2025 13:03:49 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 45472300472; Thu, 27 Feb 2025 14:03:47 +0100 (CET) Date: Thu, 27 Feb 2025 14:03:47 +0100 From: Peter Zijlstra To: Zijun Hu Cc: Zijun Hu , Greg Kroah-Hartman , Will Deacon , "Aneesh Kumar K.V" , Andrew Morton , Nick Piggin , Arnd Bergmann , Thomas Gleixner , Herbert Xu , "David S. Miller" , "Rafael J. Wysocki" , Danilo Krummrich , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Johannes Berg , Jamal Hadi Salim , Cong Wang , Jiri Pirko , Jason Gunthorpe , Leon Romanovsky , Linus Walleij , Bartosz Golaszewski , Lee Jones , Thomas Graf , Christoph Hellwig , Marek Szyprowski , Robin Murphy , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, linux-rdma@vger.kernel.org, linux-gpio@vger.kernel.org, linux-pm@vger.kernel.org, iommu@lists.linux.dev, linux-mtd@lists.infradead.org Subject: Re: [PATCH *-next 00/18] Remove weird and needless 'return' for void APIs Message-ID: <20250227130347.GA5880@noisy.programming.kicks-ass.net> References: <20250221-rmv_return-v1-0-cc8dff275827@quicinc.com> <46d17d84-5298-4460-96b0-9c62672167a0@icloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46d17d84-5298-4460-96b0-9c62672167a0@icloud.com> X-Rspamd-Queue-Id: D02D540039 X-Stat-Signature: c4zi5afzqqp4g5ax1xj9sxikja436doe X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1740661450-599917 X-HE-Meta: U2FsdGVkX19Ob7/YBchdHDeBGJFoJ9UrVocH71375lnE50OiuPUaWvG+zv9xl1gi5ErTf6ienXP4Qbbabj4BlOtvGkTGEExMAPqVBTcruTpy3TKIB1L6UlcGDvdP0gPrmoMnEFBR0aTOiIRj7uEOtNB4P7YFBlAgRiMEkr4uwbspoU3xDwi2KrPbcjPQbatgjDE4h1/vl+Ube31selZ6sYgGknKSkXAzezJA6PqxllZX9e0Nbbh7emVEq8T0AhvhGZljnVFIvB67Zas6J+kO+YrcCSVSxpbcHQFc8qOLcV3MJVsUbH+TRJIZPE8AGKfU2XSN4BFW0dVKHOazJaOc969uZhgAbmTIqsGOf8XCyXmE4IyNM1JR6/eOeF8uiI82HvYJELix056HJI0/chU7STUlAhhOYGbyP/Ub2nE1hmnX5ZeRvzpBjotrvBmYh2YWosnnMdQDZ1Cs32AnCKh7vintxmLZWEA9n3GcfQW3M+6YQW1G4S8ia7rIGEYHXfvpoJJWrbWDG8TyQ+3ptqFqZQn0E55TRKg9gSTwibbDqouhuEWHDHZvKeWzF6zRCv1Y0EkYtZNM5eb7YvQrRfiLm9Da0wRVkuSGOQlDEB63TUs08boapTksBM0eoCuVKykwJpUNOada81PpFeoff16lFaq5esfKfnpHqpYiDc8gL8j8SNcQQZJXxN3RrKibhgf3N3JseYSfKRfmSKZOBDPdxKwjT1BjiUKUtTlqtjxdq/yHtTK2mvKzIdQaCbXFOcjT1rHg5mQXpbDWlPPtaiydgE326rG8HoxDRHFxzwjPWN4cttwKUZIVAs5onUxhVyd8TbDQGryHGum+zkpPX9L5pkxk1f5u3Dp5cALi/VG8WdLYJoVi+zYKt9Fk00WpI6PUgFufv01VNFFOSSf4ZcJw8G3L2sDqooOWI/5s+5q/IAxz7KhTXFKb8r4z5zPIigV0gyreD/lrr+MZ2bQKolk 96nY5e85 KCh1tYRwNPjtoWpW5qhnvBAD+dDg1fBqU5seGzDbyfOtVQ+SzO9P55uNpWuNvV7IPsA/JLMYnFQyDepV2PYm1DKCtSlcWpbw+elTO7OID8ObI6LoVmytUPa/ASmfxYF03hkBvqHyuLsZzxZAkmnBAkTSkzF9dba0hejRqsMyxTJaKcawEDz3lJhOVNB6lBzRvS8AAtHocfSHuQOxVjXt/Pg1Fxh+t8A7I+KvhpwWiz3W9Xk1zS7z706DemsUzI9qoCx3Tqq4g9bm+/cU= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Feb 27, 2025 at 08:48:19PM +0800, Zijun Hu wrote: > On 2025/2/21 21:02, Zijun Hu wrote: > > void api_func_a(...); > > > > static inline void api_func_b(...) > > { > > return api_func_a(...); > > } > > The Usage : Return void function in void function > > IMO, perhaps, the usage is not good since: > > A) STD C does not like the usage, and i find GCC has no description > about the usage. > C11/C17: 6.8.6.4 The return statement > "A return statement with an expression shall not appear in a > function whose return type is void" We really don't use STD C, the kernel is littered with extensions. > B) According to discussion, the usage have function that return type > of the callee api_func_a() is monitored. but this function has below > shortcoming as well: > > the monitor is not needed if the caller api_func_b() is in the same > module with the callee api_func_a(), otherwise, provided the callee is > a API and provided by author of other module. the author needs to clean > up lot of usages of the API if he/she changes the API's return type from > void to any other type, so it is not nice to API provider. > > C) perhaps, most ordinary developers don't known the function mentioned > by B), and also feel strange for the usage It is quite common to do kernel wide updates using scripts / cocinelle. If you have a specialization that wraps a function to fill out a default value, then you want the return types to keep matching. Ex. return_type foo(type1 a1, type2 a2); return_type my_foo(type1 a1) { return foo(a1, value); } is a normal thing to do. The whole STD C cannot return void bollocks breaks that when return_type := void, so in that regards I would call this a STD C defect.