Re: [PATCH] man/: SYNOPSIS: Remove GNU forward-declarations of parameters for lengths of array parameters

[Alejandro Colomar <alx+linux-man@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 8203 bytes --]

Hi Martin,

> Date: 2026-10-24 20:11:10+0200
> From: Martin Uecker <uecker@tugraz.at>
>
> Am Samstag, dem 24.10.2026 um 18:37 +0200 schrieb Alejandro Colomar:
> > Hi Chris,
> > 
> > > Date: 2026-10-24 17:16:19+0100
> > > From: Christopher Bazley <chris.bazley.wg14@gmail.com>
> > > 
> > > On Sat, Oct 24, 2026 at 2:38 PM Alejandro Colomar
> > > <alx+linux-man@kernel.org> wrote:
> > > > 
> > > > > Date: 2026-10-24 09:45:02-0300
> > > > > From: "Michael Kerrisk (man7.org)" <mtk@man7.org>
> > > > > 
> > [...]
> > > > > I was unfamiliar with that syntax, but at least in context it is
> > > > > immediately understandable,
> > > > 
> > > > Actually, it is not understandable.  [static 2] doesn't mean the same as
> > > > [2], and this is one historic mistake of the C Committee that I wish had
> > > > never happened.  [static 2] is never what you want (I was tempted to say
> > > > almost never, but I've never seen a good case for it).  Programmers want
> > > > the meaning of [2].
> > > > 
> > > > The main differences between [static 2] and [2] are:
> > > > 
> > > > -  [2] means (in GNU C, and in common understanding, but not
> > > >    acknowledged by ISO C) that:
> > > > 
> > > >         -  The caller must supply at least 2 elements.
> > > >         -  The callee must not access past those 2 elements.
> > > > 
> > > > -  [static 2] means (in ISO C, but ignored by GCC):
> > > > 
> > > >         -  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)
> > > 
> > > You can, of course, document for the benefit of callers that a
> > > function does not read past the static array bound.
> > 
> > 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.
> 
> [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 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3801.txt>.

> void foo(int a[static 3]);
> void bar()
> {
> 	foo(nullptr);
> }
> 
> <source>: In function 'bar':
> <source>:5:9: warning: argument 1 null where non-null expected [-Wnonnull]
>     5 |         foo(nullptr);
>       |         ^~~
> <source>:2:6: note: in a call to function 'foo' declared 'nonnull'
>     2 | void foo(int a[static 3]);
> 
> https://godbolt.org/z/fa4YsWq63
> 
> > 
> > > >         -  The caller must supply a non-null pointer.
> > > > 
> > > > 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.
> > > 
> > > 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:
> > > 
> > > int foo(int a[static 2])
> > > {
> > >   return a[2]; // warning from SDCC
> > > }
> > > 
> > > int bar(int a[2])
> > > {
> > >   return a[2]; // warning from SDCC
> > > }
> > > 
> > > https://godbolt.org/z/zf3nPerdn
> > 
> > GCC has some partial diagnostics for out-of-bounds accesses.
> > 
> ... (example) ...
> > 
> > I wish it diagnosed as much as SDCC, but not yet.  :)
> 
> The more relevant example is this:
> 
> void foo(int n; int a[n], int n);
> void bar(int a[4])
> {
> 	foo(a, 5);
> }
> 
> <source>: In function 'bar':
> <source>:5:9: warning: 'foo' accessing 20 bytes in a region of size 16 [-Wstringop-overflow=]
>     5 |         foo(a, 5);
>       |         ^~~~~~~~~
> <source>:5:9: note: referencing argument 1 of type 'int[]'
> <source>:2:6: note: in a call to function 'foo'
>     2 | void foo(int n; int a[n], int n);
> 
> https://godbolt.org/z/hhGYTej49
> 
> This has a very real and obvious security benefit.
> 
> > ...
> 
> > > > 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.
> 
> 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.
> 
> > > > 
> > > > > and I so I don't dislike it, And it is
> > > > > standard C.
> > > > 
> > > > When the standard clashes with reality and common sense, I'm not sure
> > > > I'd give the standard much credibility.
> > > > 
> > > > >  I really don't think Linux man-pages is the place to
> > > > > introducing nonstandard, GNU-specific syntax (that people clearly
> > > > > don't understand).
> > > > 
> > > > People clearly don't understand [static 2] either.
> > > 
> > > 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:
> > 
> > My understanding is tthe same.
> > 
> > > 
> > > int len(int s[static 4])
> > > {
> > >   int i = 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
> > > 
> > > 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.
> 
> 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.
> 
> 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

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]