Hi Martin, > Date: 2026-10-25 09:40:52+0100 > From: Martin Uecker > > Am Sonntag, dem 25.10.2026 um 08:38 +0100 schrieb Alejandro Colomar: [...] > > > 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. > > Yes, please. But this would also not work for function pointer, > so I thought you meant something new. Done. I've asked Dan for a number, and sent the draft to the mailing list. > > > > 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. > > In GCC [static n] and [n] have the same meaning, except > that [static] additionally implies that the pointer is not null. > I have worked on this, so please assume I know this. Indeed, I know you know. > In ISO C it is as I said, [n] has no meaning and [static n] > is a strict subset of what we want. And I insist that ISO C should be ignored. It doesn't matter what ISO C says about it, and your statement that [1] has no meaning in parameters is giving it too much credibility. > So I am really confused about what you are trying to tell me. I'm trying to say that [1] has a meaning, even outside of GCC. Every programmer that ever wrote [n] meant the obvious thing. The fact that ISO C ignores this shouldn't be an excuse to claim that [static n] doesn't change the meaning, because it is a de-facto change of meaning. Cheers, Alex --