Hi Martin, On 9/3/22 17:31, Martin Uecker wrote: [...]
But the recent discussion about presenting nonnull pointers as [static 1] is horrible. But let's wait till the future hopefully fixes this.yes, [static 1] is problematic because then the number can not be used as a bound anymore. My experience is that if one wants to see something fixed, one has to push for it. Standardization is meant to standardize existing practice, so if we want to see this improved, we can not wait for this.
Yeah, I'm not just waiting to see if it gets fixed alone. I've been discussing about nonnull being added to the standard, or improved in the compilers, but so far no compiler has something convincing. GCC's attribute is problematic due to UB issues, and Clang's _Nonnull keyword is useless as of now:
<https://github.com/llvm/llvm-project/issues/57546>Maybe GCC could add Clang's _Nonnull (and maybe _Nullable and the pragmas, but definitely not _Null_unspecified), and add some good warnings.
Only then it would make sense to try to standardize the feature. [...]
In K&R syntax this worked for definition:
void foo(y, n)
int n;
int y[n];
{ ...
But this worked because you could reorder the
declarations so that later declarations could
refer to previous ones.
So one could do
int foo(int n, char buf[n]; buf, n);
where the second part defines the order of
the parameter or
int foo(buf, n; int n, char buf[n]);
where the first part defins the order,
but the declarations need to have the size
first. But then you need to specify each
parameter twice...
Hmm, yeah, maybe the [.n] notation makes more sense.
We thought about using this syntax int foo(char buf[.n], int n); because it is new syntax which means we can restrict the size to be the name of a parameter instead of allowing arbitrary expressions, which then makes forward references less problematic. It is also consistent with designators in initializers and could also be extend to annotate flexible array members or for storing pointers to arrays in structures:It's not crazy. I don't have much to argue against it.struct { int n; char buf[.n]; }; struct { int n; char (*buf)[.n]; };Perhaps some doubts about how this would work for nested structures, but not unreasonable.It is not implemented though...
Well, are you planning to implement it? If you do, I'm very interested in using it in the documentation ;) Cheers, Alex -- Alejandro Colomar <http://www.alejandro-colomar.es/>
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
