From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792911607; b=UvdRThNJ1P/A4IJrDLu5bUtbKVPXNMcBo78rhyX7rqGXeLPmjXUC6KEMt95LZa4RIXy+ oem5Sv5QDld97B/mcW5G2jnTBVNi7aBTBD8zQbURZ9Du6Onqk3mLNP0bsMU3Epc1Nx1FB FgbO2OP4TTQl/vFwpz5DIEDXA+RHgIzEtFnPjhaBWUztwvoN+/H1Qes5koYDcbF7omeow +Z3qHvvDr7bCNoq66OoYMMo9ycPTbtdocqH0GTsyxqHMxVS6uWQC3D/VMLCwp/Yboefmm ozxSJPXL9OElMQQzdxkYSQbvxFxLWFQaExvo2ImYXf4hPwgRmDHge/1zX2wjtmpFD7A== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792911607; h=Received:DKIM-Signature:Date:From:To:Cc:Subject:Message-ID: References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To; bh=KJNLGrFCmZVU/vifnzQrisNuudNhtiUD004yhrHX6z8=; b=SH1dvZYOQeksd29AUBtjGXR2ueH7LlYDJlxx5cL4VabwjJreXbS3R4fA6uWtb/KtXRnZ CaQtHFQ+YhASu8aFa8BYdwkD2npUjacPjm7QvAbAmMH4z7gQ12NLpa66QblBmsXXssQ9k KW4EbAK1vUSrudzqzuJpP5RsxwdrFS/r+sSRVcS7ILzhtZgb40t4XUPYpbPBVWLnQZC60 3U4UA17Lrz/OERxYGQrzpb4emQfYWaVMUKMfgYa6oAGdCTHHZyitVhFE4MpB1pAr2KBYx vcU4CjwBIG4Q+xyRu8CAyyv/3ritrvenvvHNimYhZd+4bEQyR8sEXmFSfvxm6wG3Jww== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=oKh5uUVb; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9937B606A31B for ; Sun, 25 Oct 2026 07:00:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=oKh5uUVb Received: by smtp.kernel.org (Postfix) with ESMTPSA id D859C1F01825; Sun, 25 Oct 2026 07:00:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792911606; bh=KJNLGrFCmZVU/vifnzQrisNuudNhtiUD004yhrHX6z8=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=oKh5uUVbMDzLgNrANPMKRT/8RQAZBg9Z2FGKZYEg3SqDD4bOmIjvQL5G5pd/hVZMc Lw0AREyYRsPAMTvdSr5j07HgFxlVq0XLLJABsd1Olvksgpt/HYuSm2Lm55icIzAAMb VQpVmA14uNBExz9godHDZ4m5PuTR9QiHEMGQIdibceGUGjAklJdeVlX3bnLnCedDE0 6qHROi2zYeNb+lJhai0oLPIgLwrrmGs9QX1W1aWITOS2GBH4B1ccqORiVueuTo1Px4 XsGc18JRJNUUo1BmV0mUB8hSW8Wg39at5n99AJUQVO8yQkNnJRFyL+5XJX3ff5u6kw sKx3TfRYmD7AQ== Date: Sun, 25 Oct 2026 07:59:56 +0100 From: Alejandro Colomar To: Martin Uecker Cc: Christopher Bazley , "Michael Kerrisk (man7.org)" , linux-man@vger.kernel.org, Michael Kerrisk , Sam James , Carlos O'Donell , "Joseph S. Myers" , corbet@lwn.net Subject: Re: [PATCH] man/: SYNOPSIS: Remove GNU forward-declarations of parameters for lengths of array parameters Message-ID: References: <79b27ba6d0eb7a511f23607a4f3612d4f6911f24.1792687206.git.alx@kernel.org> X-Mailing-List: linux-man@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3ng3ziqimmpu5grd" Content-Disposition: inline In-Reply-To: --3ng3ziqimmpu5grd Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable From: Alejandro Colomar To: Martin Uecker Cc: Christopher Bazley , "Michael Kerrisk (man7.org)" , linux-man@vger.kernel.org, Michael Kerrisk , Sam James , Carlos O'Donell , "Joseph S. Myers" , corbet@lwn.net Subject: Re: [PATCH] man/: SYNOPSIS: Remove GNU forward-declarations of parameters for lengths of array parameters Message-ID: References: <79b27ba6d0eb7a511f23607a4f3612d4f6911f24.1792687206.git.alx@kernel.org> MIME-Version: 1.0 In-Reply-To: Hi Martin, > Date: 2026-10-24 20:11:10+0200 > From: Martin Uecker > > Am Samstag, dem 24.10.2026 um 18:37 +0200 schrieb Alejandro Colomar: > > Hi Chris, > >=20 > > > Date: 2026-10-24 17:16:19+0100 > > > From: Christopher Bazley > > >=20 > > > On Sat, Oct 24, 2026 at 2:38=E2=80=AFPM Alejandro Colomar > > > wrote: > > > >=20 > > > > > Date: 2026-10-24 09:45:02-0300 > > > > > From: "Michael Kerrisk (man7.org)" > > > > >=20 > > [...] > > > > > I was unfamiliar with that syntax, but at least in context it is > > > > > immediately understandable, > > > >=20 > > > > Actually, it is not understandable. [static 2] doesn't mean the sa= me as > > > > [2], and this is one historic mistake of the C Committee that I wis= h had > > > > never happened. [static 2] is never what you want (I was tempted t= o say > > > > almost never, but I've never seen a good case for it). Programmers= want > > > > the meaning of [2]. > > > >=20 > > > > The main differences between [static 2] and [2] are: > > > >=20 > > > > - [2] means (in GNU C, and in common understanding, but not > > > > acknowledged by ISO C) that: > > > >=20 > > > > - The caller must supply at least 2 elements. > > > > - The callee must not access past those 2 elements. > > > >=20 > > > > - [static 2] means (in ISO C, but ignored by GCC): > > > >=20 > > > > - The caller must supply at least 2 elements. > > > > - The callee is free to access past those 2 elements!! > > > > (of course, if there aren't any elements after that, it'= s UB) > > >=20 > > > You can, of course, document for the benefit of callers that a > > > function does not read past the static array bound. > >=20 > > Comments are bound to be wrong in the future, often near future. It's > > better to not use the feature, because it's not necessary. Just use > > [2], and ask your compiler to be better than what ISO C requires. >=20 > [static ...] implies that the pointer is not null, this is > a standard compliant way to express this (it implies a bit > more as nonnull, but compilers do not support more). Still, > it gives you a real practical security benefit. I know you can get usefulness out of it, but the fact that you must express a bound and that it doesn't mean what everyone would expect it to mean makes it a broken feature, unless and until we fix the second bullet by making [static n] mean the same as [[gnu::nonnull]] [n], which is n3801 . > void foo(int a[static 3]); > void bar() > { > foo(nullptr); > } >=20 > : In function 'bar': > :5:9: warning: argument 1 null where non-null expected [-Wnonnull] > 5 | foo(nullptr); > | ^~~ > :2:6: note: in a call to function 'foo' declared 'nonnull' > 2 | void foo(int a[static 3]); >=20 > https://godbolt.org/z/fa4YsWq63 >=20 > >=20 > > > > - The caller must supply a non-null pointer. > > > >=20 > > > > The null-pointer issue is nonsense, but we can live with it. > > > > The allowance to access past the specified length, that's the real = issue > > > > with this feature, and why it should not be used at all. > > >=20 > > > Of the compilers I have tried, only SDCC currently warns about access > > > past the specified length, and it does so regardless of whether the > > > length is specified using 'static' or not: > > >=20 > > > int foo(int a[static 2]) > > > { > > > return a[2]; // warning from SDCC > > > } > > >=20 > > > int bar(int a[2]) > > > { > > > return a[2]; // warning from SDCC > > > } > > >=20 > > > https://godbolt.org/z/zf3nPerdn > >=20 > > GCC has some partial diagnostics for out-of-bounds accesses. > >=20 > ... (example) ... > >=20 > > I wish it diagnosed as much as SDCC, but not yet. :) >=20 > The more relevant example is this: >=20 > void foo(int n; int a[n], int n); > void bar(int a[4]) > { > foo(a, 5); > } >=20 > : In function 'bar': > :5:9: warning: 'foo' accessing 20 bytes in a region of size 16 [-= Wstringop-overflow=3D] > 5 | foo(a, 5); > | ^~~~~~~~~ > :5:9: note: referencing argument 1 of type 'int[]' > :2:6: note: in a call to function 'foo' > 2 | void foo(int n; int a[n], int n); >=20 > https://godbolt.org/z/hhGYTej49 >=20 > This has a very real and obvious security benefit. >=20 > > ... >=20 > > > > The committee was clearly confused when they added this feature. > > > > It was around the time when 'restrict' was added, which is another > > > > historical mistake of the committee. In general, every feature they > > > > added thinking of optimizations (and that includes these two) has > > > > resulted in a mistake. >=20 > It was not a mistake, it was a different set of priorities It was a mistake. They thought it would provide room for optimizations, but nobody checked whether it was actually useful in the real world. This seems to me a clear example of a design looking for users, which is precisely what the C Committee should *not* do. > We now have more users and people interested in safety in > the committee, but powers could easily shift back. >=20 > > > >=20 > > > > > and I so I don't dislike it, And it is > > > > > standard C. > > > >=20 > > > > When the standard clashes with reality and common sense, I'm not su= re > > > > I'd give the standard much credibility. > > > >=20 > > > > > I really don't think Linux man-pages is the place to > > > > > introducing nonstandard, GNU-specific syntax (that people clearly > > > > > don't understand). > > > >=20 > > > > People clearly don't understand [static 2] either. > > >=20 > > > My understanding is that [static 2] was introduced to facilitate cases > > > like the following, where an implementation could theoretically > > > generate code that reads the first four elements together, but would > > > have to load subsequent elements individually: > >=20 > > My understanding is tthe same. > >=20 > > >=20 > > > int len(int s[static 4]) > > > { > > > int i =3D 0; > > > do > > > { > > > if (!s[i]) break; else ++i; > > > if (!s[i]) break; else ++i; > > > if (!s[i]) break; else ++i; > > > if (!s[i]) break; else ++i; > > > } while (1); > > > return i; > > > } > > > https://godbolt.org/z/ra6zh7Ej3 > > >=20 > > > I have never yet managed to persuade a compiler to optimise such code > > > differently from a version without 'static 4', and I struggle to > > > believe it would ever be beneficial to do so. The more obvious case, > > > where an array bound such as [static 4 * n] potentially enables > > > speculative loads when unrolling a loop with an early exit, does not > > > need the compiler to be permitted to generate code that reads beyond > > > the passed-in array bound. >=20 > I think the idea of limiting access to the rest of the array did > not occur to them, as this feature was only for optimization. And that's what I call a mistake; a big one. > > And indeed, I agree. This seems a case of bad design, wishing that it > > might eventually be optimizable, while it wasn't and still isn't, and > > also while ignoring the safety issues caused by it. We should just > > pretend that the feature doesn't exist. >=20 > It would potentially be useful for optimization, but I think there > was a chicken-and-egg problem. Nobody used [static] and then > people worked on instead optimizations more useful for existing code, > so [static] also never become useful for programmers. That's the right approach. > Much later it become useful to express non-null pointers. It still hasn't. It will once we get rid of the bound. That is, it will be useful when one can do [static] or [static *]. And even then, the fact that it can't be used on function pointers makes it a bad patch in the language. We need a feature that is consistent. And we also have the issue that it changes the meaning of the bound. It's just terrible. Have a lovely day! Alex --=20 --3ng3ziqimmpu5grd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEES7Jt9u9GbmlWADAi64mZXMKQwqkFAmrdqOUACgkQ64mZXMKQ wqlF+w/+KxnHe89Dhxovv6mRoDMitleeTyxx/hogpmJJa/wyE2DOy7FZ7PoK5HlH lTIwCMO9b9yYCwbF8Qa+UevU015FT1391JG7VxMIJC8D6NBGeVmXM3w4ZeWD0fHV LeAObeBDREWOl+3c5NrHAZnz6MTV1YmNGEEbGQ6ONcwN6J9l3RJ3ArGDXwAb3DkV sq3wRX5td+JcZ0TDnUOcdkP9f8kVUU82qAnag7adkPHN8zM68KB2+w2FLem0AXB7 t5vhR7n+AEVkdCMVi/9PlPlszgPQ+X7eDWTjmw7FCjqbn/RGbapPg6rh7fKT+hhd 5AhooEPRxBrygUO5p/WzBV/6R+EPgDKTW0Snz2Z6OrVl2VjqRkC29sMrxXoe7ssz gi5C1zhW1tslyvraF9qF/VNJNuYYtRxI1XNW2ONHbZOM2JvGlfaedebYlOPgTfOu slm7qPrQ0F6d8MwJ/FrWlbyi1g8nrx6GqpEqLbgkFA+Rlqhy+0vFEXGy4UeN9DxT ngskk/DGQqkTJC7v8PPRiykL/StYhLPKAyGmGMw/A/A2XjYLvL0nAYQpvMN50kw+ ei6cGjdyj+1IHzWxSOt+9hK3g17q3u0/OEzHJDW5aRLlqty9rYBe+GSTrn0omDeW 9ZiogSTvFnwP3nA+QxntrIqpPmmxP8hFTVjt6BS3LIZF7LOl2Rk= =Mu4P -----END PGP SIGNATURE----- --3ng3ziqimmpu5grd--