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 71885C83F1D for ; Tue, 15 Jul 2025 07:08:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E40406B0092; Tue, 15 Jul 2025 03:08:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E17A16B0093; Tue, 15 Jul 2025 03:08:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D548F6B0095; Tue, 15 Jul 2025 03:08:25 -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 C58256B0092 for ; Tue, 15 Jul 2025 03:08:25 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 531471C9131 for ; Tue, 15 Jul 2025 07:08:25 +0000 (UTC) X-FDA: 83665620570.30.B1B82D3 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf08.hostedemail.com (Postfix) with ESMTP id 7B0E5160009 for ; Tue, 15 Jul 2025 07:08:23 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=TP0IAAkR; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf08.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=1752563303; 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=wgOy1FmSDbs+GUCR+IA9ljOb//Y1Ab7h6QXhOcw1yfU=; b=jvzLCtTMAm7jZGkIKHJMqRTMOGNHQ+95PDAjljv6GnJmhMeAKfAN5Byw7FpYRegxzpx47g 8QRaddnKhapUA1xK4VGgzJUwbCjx0fY2xPJsJ4If0LnacjeRVE4qxdMGx6eVdwEijMAY2e hC1yt23s99XQkzlmPPM9OQb78JGg5cc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752563303; a=rsa-sha256; cv=none; b=k6jld2Qx78QgVKPyKZTClam4cZWEKU7kJei7UUW9nKsE5rdsdakUzsNT59dJ5HnXiIbNFY DoxjtC1z3KBho9D09jqGu8vOLkMVBZjikbuSEut18IVwSKtoBgaxNYLSLOTD6b1BOFrHY3 nWG1nRHKA/rlPcHs/TkaVNAksqesi4k= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=TP0IAAkR; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf08.hostedemail.com: domain of alx@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=alx@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 068BB436A4; Tue, 15 Jul 2025 07:08:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D79EBC4CEE3; Tue, 15 Jul 2025 07:08:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1752563301; bh=ZtiA5UaAo10PuFq9JB+iuvdAzJQmh2KZPxbpkCfnVKo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TP0IAAkR+uae0ksBiq7ASGeMFdtCf/dbiqAmqyydEjE2esjWnXae/M550GQq2ZpWB ED3dS3hQxlpS6Nd/s/xKsZWeNivID86Np8+NLoiaPEn6oRsHuqog08KiealyUGcmvT CDOCm6veFUcBovjuBmlGIQftqM1tqys/PQ3j8eiT1V2xNbAPqcSL5dRHWvx2NYUizk a0XFqSoze9mhTlvgpmWS1R7ERajbtMGJ2ki4yqvAKG4QE1PqDU1B9E38qays/6UrBf d1thz1nnsowj+k1RX+3Qzb8RW6YlvTCjEnkyxuZWkEiiXTcTkSnNbCrdg+2VapcVDm HbAnDdCOo2p3g== Date: Tue, 15 Jul 2025 09:08:14 +0200 From: Alejandro Colomar To: Kees Cook Cc: Linus Torvalds , David Laight , Martin Uecker , linux-mm@kvack.org, linux-hardening@vger.kernel.org, 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 , Rasmus Villemoes , Michal Hocko , Al Viro , Sam James , Andrew Pinski Subject: Re: [RFC v5 6/7] sprintf: Add [v]sprintf_array() Message-ID: <3o3ra7vjn44iey2dosunsm3wa4kagfeas2o4yzsl34girgn2eb@6rnktm2dmwul> References: <04c1e026a67f1609167e834471d0f2fe977d9cb0.1752182685.git.alx@kernel.org> <28c8689c7976b4755c0b5c2937326b0a3627ebf6.camel@gmail.com> <20250711184541.68d770b9@pumpkin> <202507142211.F1E0730A@keescook> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="42cidsdllbjeiguv" Content-Disposition: inline In-Reply-To: <202507142211.F1E0730A@keescook> X-Stat-Signature: at4re5kiqhfug1yo3sjtdcjtfp7ea4tx X-Rspamd-Queue-Id: 7B0E5160009 X-Rspamd-Server: rspam10 X-Rspam-User: X-HE-Tag: 1752563303-452802 X-HE-Meta: U2FsdGVkX1+u0AVcJMrPNhbB7XwE7ni+bTzDh6JRzZM4dKEmkMTxmj5zXNUfrYvEloCrVLROEjsWkd21hNM3WZfNGUEDd265pX++t4OKJyDuaQQYma5niU0+ehHfhhl0N/yxgQS8aGuslnEpH3kyQDGQcYuc6FZpnryFRUMnKp5gd0aaqchLf0/Yqoxf6lMdtcrsU38dHUOuILkmNgfP3+eWVoIDe3WbXg7uICssdLPnjOu+fXFuIUHXXu7yCI/ehQkEvPng3mOKY6qyWEAC0yOLHCEscgJQjoHlSNYR/QW7FCIRSe7mQ5AzYMvaFUiVbtJMG8KhG91Dd+lOYixSGtsiiQgqbWx75gN5fsAsl7UgAoihLExhBWis6y4Lr2dLhpW3CmNLspG2K/77geVxwgQ7/uNMQd8MzRpdvNAXX1erTAzbKHxME+Nnsrm6A0h7Me51ToZGsSxWbSorER5nMjRzibxVF8p2F163dm53G8tLSSokprrUhKLgpjgl/HexAzXkyLa7ZaTOFLOFnTg5RiSzd4bVrzBHXSQiwQSwl9aFMst5s2S+haBDcTWJONTeY7jRgXgpSF/VOAuo37svlL63s9tmclNsyrVh3YYiXwnOpFx/PlE3qXpF3KSOKWKdvCT2A3srkvs9ptSoTz+Lt0A4GsGTfUXbHKjQwcjsGBGPaC2NqGMERq06d6GVx2VhvsgKlHbNGbPavqktUq7b6lLAOtvf6GPSTqz75t6n6N0LuXD0ym8jfozklxKN5T1gD75hUjrDFxLApxUUF5okqjreQmnISFg36d64CBxt/XSWM5NyPZ7JQGebz4Ol1aSQN2inn4pekd+TMejdR7dkDRUrFUAy00kNC9OoXRY2kclczK5/rJG3jfOlXNH532nhkLVFPevYuMH5q6EqkA4sJVbtwplrj4Y3+Jq8mrCsrzTYeDE08Byk4BWtU/j+Xg21J1XD9SHAi20uVkC0pMN 96yfv89/ zQpJqs+DTlHG9e5coiZTTAE7CqsrJYZfvkLyCnObfVg3dDrXwsqEGiWYER3Dwyp3kXqbDmOld6iDejCsNFhrs6ycJgEapzvHCsY+7ly+Iv5KJNLRQdlO5A1hHU5LbQtho+79qB435Pkipkvc6FwzGP44Crqb4dGV9xkvu+ShIfJDDa/5dXOxgF7p1iBzuBNRzaNQqYeqAy95vCxtKXdgF4KtKwcFXLRP8CuzZYyWmok33PIM0U2Yw1Mic/ix5dDRL/b2VzPdrbJmvOY5fi04Nd/nnXe7hBrPhap/o8xzJknX2b21LQ/DghVKWyQQNvKyN7Sgq7Qgp8yCbMkT/6jd8a8blMMN+yPoB/2irwFL/klN5asaVIhHFPG6v8Wb9lAADjG+RCONDte5FQ0Q2CW1d4kxxYjGL+GGQzmpqAEYOhZm2OUcUvNPL1gMxzHh8ncV6l56ZKbsrUxtRl6cIJJ9VxlwzCyD2ux12wVk6E18R9s8r0LFpRtvvrL4u7s0vDjR9vytRinqL/YmEBs5+mDuyA2vlNg== 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: --42cidsdllbjeiguv Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable From: Alejandro Colomar To: Kees Cook Cc: Linus Torvalds , David Laight , Martin Uecker , linux-mm@kvack.org, linux-hardening@vger.kernel.org, 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 , Rasmus Villemoes , Michal Hocko , Al Viro , Sam James , Andrew Pinski Subject: Re: [RFC v5 6/7] sprintf: Add [v]sprintf_array() References: <04c1e026a67f1609167e834471d0f2fe977d9cb0.1752182685.git.alx@kernel.org> <28c8689c7976b4755c0b5c2937326b0a3627ebf6.camel@gmail.com> <20250711184541.68d770b9@pumpkin> <202507142211.F1E0730A@keescook> MIME-Version: 1.0 In-Reply-To: <202507142211.F1E0730A@keescook> Hi Kees, On Mon, Jul 14, 2025 at 10:19:39PM -0700, Kees Cook wrote: > On Fri, Jul 11, 2025 at 10:58:56AM -0700, Linus Torvalds wrote: > > struct seq_buf s; > > seq_buf_init(&s, buf, szie); >=20 > And because some folks didn't like this "declaration that requires a > function call", we even added: >=20 > DECLARE_SEQ_BUF(s, 32); >=20 > to do it in 1 line. :P >=20 > I would love to see more string handling replaced with seq_buf. The thing is, it's not as easy as the fixes I'm proposing, and sprintf_end() solves a lot of UB in a minimal diff that you can dumbly apply. And transitioning from sprintf_end() to seq_buf will still be a possibility --probably even easier, because the code is simpler than with s[c]nprintf()--. Another thing, and this is my opinion, is that I'm not fond of APIs that keep an internal state. With sprintf_end(), the state is minimal and external: the state is the 'p' pointer to where you're going to write. That way, the programmer knows exactly where the writes occur, and can reason about it without having to read the implementation and keep a model of the state in its head. With a struct-based approach, you hide the state inside the structure, which means it's not so easy to reason about how an action will affect the string, at first glance; you need an expert in the API to know how to use it. With sprintf_end(), either one is stupid/careless enough to get the parameters wrong, or the function necessarily works well, *and is simple to fully understand*. And considering that we have ENDOF(), it's hard to understand how one could get it wrong: p =3D buf; e =3D ENDOF(buf); p =3D sprintf_end(p, e, ...); p =3D sprintf_end(p, e, ...); p =3D sprintf_end(p, e, ...); p =3D sprintf_end(p, e, ...); Admittedly, ENDOF() doesn't compile if buf is not an array, so in those cases, there's a chance of a paranoic programmer slapping a -1 just in case, but that doesn't hurt: p =3D buf; e =3D buf + size; // Someone might accidentally -1 that? I'm working on extending the _Countof() operator so that it can be applied to array parameters to functions, so that it can be used to count arrays that are not arrays: void f(size_t n, char buf[n]) { p =3D buf; e =3D buf + _Countof(buf); // _Countof(buf) will evaluate to n. ... } Which will significantly enhance the usability of sprintf_end(). I want to implement this for GCC next year (there are a few things that need to be improved first to be able to do that), and also propose it for standardization. For a similar comparison of stateful vs stateless functions, there are strtok(3) and strsep(3), which apart from minor differences (strtok(3) collapses adjacent delimiters) are more or less the same. But I'd use strsep(3) over strtok(3), even if just because strtok(3) keeps an internal state, so I always need to be very careful of reading the documentation to remind myself of what happens to the state after each call. strsep(3) is dead simple: you call it, and it updates the pointer you passed; nothing is kept secretly from the programmer. Have a lovely day! Alex --=20 --42cidsdllbjeiguv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEES7Jt9u9GbmlWADAi64mZXMKQwqkFAmh1/lcACgkQ64mZXMKQ wqkuig//S3hiwlkmTsz7a0bec7iYCPTHlJQErIaH1hA0PDwadlm0Uld/f8mbbM7o Ps84e7sweLABRiI8zlkgBCM4sK3SY+wyoKz7d9vasg5XiyIVVAPxE3PaArxdTYz5 0eEJpu96pwyMyMk5efylDBnL7q7C2orgiimax53nITbsbQs3gx5rrT1eAFjQ18fk SWYjiO4LTE+vn/XWYSm/RJQpTRkss67jMrxNTg534J8NG3WRAK4q4ytJPxd3cCrB 1EQs5McuvHSVYcRCqdSfW4BK4EF1gQwwfBGh6VEX/t+i7K4tufhSeaQUGU1x4xmx ERW0AWe80VDMCyz1hmZkyEj/4r4nXn1hZ8Tjg/bvUK5WDICFKfaTGgd4EbQ4yyuY +GGOGLpHF/LzIQfGsAMLhv6QCgRd29bT3EHlCSdqpQYYDcBvCY/yCzS19q9C/5r+ kZBJGn0g+hStrC1CjItE8yrviowVmopVLsx5d3cEnjdK1FqZX8OgfWjNdDR6d0dl Ypk3D6e857x/WBd2p19r6k+Qda0Mw0KDLz/qZ0aoEjGoyBj2s86Ipi3aA54MqJyV YV/c78fOIDQB4PC+AfsvQ9xYO8Ij264dGBnHJunjZGsL1pTwVSlOnjdVw6gVsr8p bUsCwLZLs4q1EEFG4RELMcCvjXBoziYheUg2rvW5+lkV/ZPVryI= =tD+S -----END PGP SIGNATURE----- --42cidsdllbjeiguv--