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: 4556 bytes --]

Hi Martin,

> Date: 2026-10-25 08:22:23+0100
> From: Martin Uecker <uecker@tugraz.at>
>
> Am Sonntag, dem 25.10.2026 um 07:59 +0100 schrieb Alejandro Colomar:
> > Hi Martin,
> > 
> > > Date: 2026-10-24 20:11:10+0200
> > > From: Martin Uecker <uecker@tugraz.at>
> > > 
[...]
> > > [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>.
> 
> I know. Is this on the agenda?

No; it has wording issues pointed out by Joseph, and I don't have the
time or energy to address them at the moment.  See [SC22WG14.36403] in
the mailing list.

Feel free to take over the paper if you have a good idea for those.
I plan to come back to it, but not this year.

[...]
> > > > > > 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.
> 
> I would assume it came from cray and they had real world
> use case for this at that time.

What is 'cray'?

[...]
> > > 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.
> 
> Yes, but we do not even have a proposal and [static 1] exists today.

Actually, we do have one: n3803.
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3803.txt>

The wording on this one is good.  I think I forgot some trivial
duplication of the diff for both the non-abstract and the abstract
declarators, but I can fix that when I arrive home, so we could have it
in time for the next meeting.

> > 
> > And we also have the issue that it changes the meaning of the bound.
> > It's just terrible.
> 
> The bound in [1] has no meaning in parameters,

This is not true.  ISO C is just toilet paper in this regard.
It has a meaning in SDCC and GCC, and every programmer that ever wrote
[1] assigned a meaning to it.  Moreover, I'm using [1] myself to express
pointers to exactly 1 element.

> so [static 1] changes
> the meaning only in a sense that that it has a stricter meaning
> that is still only a subset of what we want. 

This is just not true.  The standard is meaningless when it clashes with
reality and common sense.  As Capt. Barbossa would say, "the [standard]
is more what you'd call "guidelines" than actual rules.  Welcome aboard
the Black Pearl, Miss Turner!"


Cheers,
Alex

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

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