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

[Alejandro Colomar]

Hi Joseph,

On 11/12/22 15:54, Joseph Myers wrote:
> On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:
> 
>> Since it's to be used as an rvalue, not as a lvalue, I guess a
>> postfix-expression wouldn't be the right one.
> 
> Several forms of postfix-expression are only rvalues.
> 
>>> (with a special rule about how the identifier is interpreted, different
>>> from the normal scope rules)?  If so, then ".a = 1" could either match
>>> assignment-expression directly (assigning to the postfix-expression ".a").
>>
>> No, assigning to a function parameter from within another parameter
>> declaration wouldn't make sense.  They should be readonly.  Side effects
>> should be forbidden, I think.
> 
> Such assignments are already allowed.  In a function definition, the side
> effects (including in size expressions for array parameters adjusted to
> pointers) take place before entry to the function body.

Then, I'm guessing that rules need to change in a way that .initializer cannot 
appear as the left operand of an assignment-expression.

That is, for the following current definition of the assignment-expression (as 
of N3054):

assignment-expression:
     conditional-expression
     unary-expression assignment-operator assignment-expression

The unary-expression cannot be formed by a .initializer.

Would that be doable and sufficient?

Cheers,

Alex

> 
> And, in any case, if you did have a constraint disallowing such
> assignments, it wouldn't suffice for syntactic disambiguation (see the
> previous point I made about that; I have some rough notes towards a WG14
> paper on syntactic disambiguation, but haven't converted them into a
> coherent paper).
> 

-- 
<http://www.alejandro-colomar.es/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20221112/e8efe876/attachment-0001.sig>