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 0CB4BC71130 for ; Tue, 8 Jul 2025 02:20:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8D1268D0002; Mon, 7 Jul 2025 22:20:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 881F38D0001; Mon, 7 Jul 2025 22:20:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7981A8D0002; Mon, 7 Jul 2025 22:20:49 -0400 (EDT) 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 69A978D0001 for ; Mon, 7 Jul 2025 22:20:49 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 270258042F for ; Tue, 8 Jul 2025 02:20:49 +0000 (UTC) X-FDA: 83639494218.25.D40A1ED Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf29.hostedemail.com (Postfix) with ESMTP id 661D712000B for ; Tue, 8 Jul 2025 02:20:47 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=SfVuVxjD; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf29.hostedemail.com: domain of alx@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=alx@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751941247; a=rsa-sha256; cv=none; b=NV6T7PKER+u/zftOajShI+UK5qcoKzJaDJ7vtigCYow4SgWU4iaXlyiuEAy6ppURn15Hq8 fo27VwKF2Pp2xHD1sTjcugyp2UyOkrs+0B8nHDX/kj9enUIig+4B42WQKyVLsgarpTfbLe /HMUmvaru9ams+hiZ0mcvFAy9Q0TRGM= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=SfVuVxjD; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf29.hostedemail.com: domain of alx@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=alx@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751941247; 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=s8p/5XWM6vjjEz1QPiqKBJehgSk+4YR1hgsGa0W7OiE=; b=n18jwUg3M8qhfSREjdK+y6ld+5VHeWjKwFx29r1EKD+R/MxkvMfSpo/fPsB9tEXg6aN01S So8wAu4UBDlXfIMUaD0s6niDvLyHw/BDdyz9jO7Cd8yKRIRAE1HMVv6MwKDAfw26Ki4nIp 9uWXlBSYoPS1dTZVl6+HCg7s9qhex18= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 4E911437F9; Tue, 8 Jul 2025 02:20:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A883DC4CEE3; Tue, 8 Jul 2025 02:20:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751941246; bh=FdNfW5qOTMVaMNJhf3d4aC3Y6ZkzpECAp4ZXPawuD1w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SfVuVxjDeHku7nPebEN4INSCvz6v89PVacBhg+NKah3iNBJs03PDRf+a+L4WHDLFf WN3uU2ocnUZAC5bIH/o0S8/qEpkJ/0I+oKfWaSmTOwD8jiiXyfoIkJXkQyLlarsQSQ zx5vCDH039tT51IGeUK1eV8qgTLEEaLvHGDEcsRTv15018+op0ewQehONP+7NB7AIk PMcGcXIbzs7t9S+Q/P+reRNeDudJ9WAON7SZsyFFHPtF7yUTGkVKtj4u9lOkFmRg9D JWu2J4YLfmN1MlhW31UUPbUqdaFfpPY7OGzYgaxgmRjVsjvtkEKxWvcRgXnTEOcE0M DhpVpRTUWCpMw== Date: Tue, 8 Jul 2025 04:20:43 +0200 From: Alejandro Colomar To: Linus Torvalds Cc: linux-mm@kvack.org, linux-hardening@vger.kernel.org, Kees Cook , Christopher Bazley , shadow <~hallyn/shadow@lists.sr.ht>, linux-kernel@vger.kernel.org, Andrew Morton , kasan-dev@googlegroups.com, Dmitry Vyukov , Alexander Potapenko , Marco Elver , Christoph Lameter , David Rientjes , Vlastimil Babka , Roman Gushchin , Harry Yoo , Andrew Clayton , Sven Schnelle , Heiko Carstens , Tvrtko Ursulin , "Huang, Ying" , Lee Schermerhorn , Christophe JAILLET , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Chao Yu Subject: Re: [RFC v3 3/7] mm: Use seprintf() instead of less ergonomic APIs Message-ID: References: <033bf00f1fcf808245ae150346019aa7b997ea11.1751862634.git.alx@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 661D712000B X-Stat-Signature: 3drw4stn5mnyi14au9e59wy7udu3m7tx X-Rspam-User: X-HE-Tag: 1751941247-362662 X-HE-Meta: U2FsdGVkX18n8X0vAAPi5RiRAZ1KLRIcr21p3upc4KNl5aGotBDGUOOOZzBPPKon2kKsCToAj7dizeaRdbT0SmCX2iCkaXcV8MYGmPpwPO4W0PYPJG+YDBdPDFK6i7aNmNTO1AfVfv8VaqVnixBjHY+lNpOR5k9QY9Fx+ILVz53IjpSDz4UQmTa4Wbhr7VU12dmtStpUo5/sBAM8bpdbXyQdt8THBL/5tQ/0jqhYLxesm7UnfbWQTQTeRzXfN+5c6ZvzTCJ6WCkAggLFX+BiyKP63vbsh6mQI0Xcb6DdXZtvJoN8EYHfwP3pK1fW2lLsc/Ad22zoNue39jH8YqOtqzmGlqPeZD9/MD0IrCuV6ggzsK16Ci60hzCYx8l/7yi3dVmQRKo2sIzzmYhlzfjGft1pduPUwKzHfzLhy2WkcFZHryMLBiRwbd94YSgRnTWAo/nMcYKxKCYR1wm+CJzyM9EuvKW4jgdaCCBeKcRc+/oK8CcR0aAzXif3vpod4fEjG2QE3WrdP+A5AwJ1zyQTSzxcdaHo5Nce9X5NwWqftXW7ZJPhzpw1DwxTMZ+Xb2xCBWiYWrmkPfrog/a/RF5yuckB8uQ/tiOQnPgFM5bFyYKF7fwjbCFdNFIXMY3HvkBhxEGAI5OELO5oArcVzZrx3YLJB3ho1UbboS0ZPH2fwhb3IWm8G8QhheCURst2LtphyX0sAJIODctUwl11U/LEUBH44wMQCNuGQ8aNKPnxUKyR5EpItiMqoaBt80YXTENjAvK95+oujbnieuOIXeTSh/FpR5RNs7MowErdUkPsMGE5wjjeD/UJ9KjvhA4IhIICd3r9WhH9gjDakbO0SH6BTh6UGZRYIhnNsrCgEfEa/gVR8ZateGgwN3TIHHv8ur1sOvphD1SFO1riG99XF98OvOkKGy6/zvqV4JLwmsu7pTOFxor8HVcpAK4KBCIVtSaniSFv8hDo7rDYF4k3ESJ 2WH9rtfz yvmqUJLAXtBAV7sQsbEAJss/7gzayWb1L+17njU1+Wmmz6oReE4sGoNPxtAR4ck6gibvRPgJUaN0nY8RBK6iHhYkQ6Cy7EMELypS2N5eDh0VM0sCg5Ey/6OW/e0NQbBTtPAU/gwZ6Ji2Xpa6dmUCYjG9NkXnY+PPZReFSrgg83EDFBW53iMvaTK4yZYaFKri6RhHZyQPhhvPEWy980kRssHGdcSozuSiU3ldYtLHuh6fqbfu/0lj12wb6F8edzefisfbYgp8aNmlC36bJ2k3a63bGwe+5H+snEJY5BRnUbmrd5rFzTWxReNpxowZIMxVPTcvm1qQtF5hpIgKcsrbAv6EropnV3lj+mESLmV5zQ0kkoyZHxLGuI3Q0PWtWOmRanDClLvoF5E4onKZLYhEXOeIMPQ== 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: Hi Linus, On Mon, Jul 07, 2025 at 03:17:50PM -0700, Linus Torvalds wrote: > On Mon, 7 Jul 2025 at 14:27, Alejandro Colomar wrote: > > > > If the name is your main concern, we can discuss a more explicit name in > > the kernel. > > So as they say: "There are only two hard problems in computer science: > cache invalidation, naming and off-by-one errors". Indeed. And we have two of these classes here. :) > And the *worst* model for naming is the "add random characters" (ok, I > still remember when people believed the insane "Hungarian Notation" > BS, *that* particular braindamage seems to thankfully have faded away > and was probably even worse, because it was both pointless, unreadable > _and_ caused long identifiers). To be fair, one letter is enough if you're used to the name. Everything of the form s*printf() people know that the differentiating part is that single letter between 's' and 'p', and a quick look at the function prototype usually explains the rest. More than that, and it's unnecessarily noisy to my taste. But not everyone does string work all the time, so I get why you'd be less prone to liking the name. I won't press for the name. Unless you say anything, my next revision of the series will call it sprintf_end(). > Now, we obviously tend to have the usual bike-shedding discussions > that come from naming, but my *personal* preference is to avoid the > myriad of random "does almost the same thing with different > parameters" by using generics. > > This is actually something that the kernel has done for decades, with > various odd macro games - things like "get_user()" just automatically > doing the RightThing(tm) based on the size of the argument, rather > than having N different versions for different types. In this case, I wouldn't want to go that way and reuse the name snprintf(3), because the kernel implementation of snprintf(3) is non-conforming, and both the standard and the kernel snprintf() have semantics that are importantly different than this API in terms of handling errors. I think reusing the name with slightly different semantics would be prone to bugs. Anyway, sprintf_end() should be clear enough that I don't expect much bikeshedding for the name. Feel free to revisit this in the future and merge names if you don't like it; I won't complain. :) Have a lovely night! Alex P.S.: I'm not able to sign this email. > So we actually have a fair number of "generics" in the kernel, and > while admittedly the header file contortions to implement them can > often be horrendous - the *use* cases tend to be fairly readable. > > It's not just get_user() and friends, it's things like our > type-checking min/max macros etc. Lots of small helpers that > > And while the traditional C model for this is indeed macro games with > sizeof() and other oddities, these days at least we have _Generic() to > help. > > So my personal preference would actually be to not make up new names > at all, but just have the normal names DoTheRightThing(tm) > automatically. > > But honestly, that works best when you have good data structure > abstraction - *not* when you pass just random "char *" pointers > around. It tends to help those kinds of _Generic() users, but even > without the use of _Generic() and friends, it helps static type > checking and makes things much less ambiguous even in general. > > IOW, there's never any question about "is this string the source or > the destination?" or "is this the start or the end of the buffer", if > you just have a struct with clear naming that contains the arguments. > > And while C doesn't have named arguments, it *does* have named > structure initializers, and we use them pretty religiously in the > kernel. Exactly because it helps so much both for readability and for > stability (ie it catches things when you intentionally rename members > because the semantics changed). > > Linus --