Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Alejandro Colomar <alx.manpages@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2782 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]