Hi Martin, > Date: 2026-10-25 08:22:23+0100 > From: Martin Uecker > > 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 > > > [...] > > > [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 . > > 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. 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 --