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

Joseph Myers
2022-11-14T18:14:15Z

On Sun, 13 Nov 2022, Alejandro Colomar via Gcc wrote:

> SYNOPSIS:
>
> unary-operator: . identifier

That's not what you mean. See the standard syntax.

unary-expression:
[other alternatives]
unary-operator cast-expression

unary-operator: one of
& * + - ~ !

> - It is not an lvalue.
>
> - This means sizeof() and _Lengthof() cannot be applied to them.

sizeof can be applied to non-lvalues.

> - This prevents ambiguity with a designator in an initializer-list within
> a nested braced-initializer.

No, it doesn't. See my previous points about syntactic disambiguation
being a separate matter from "one parse would result in a constraint
violation, so choose another parse that doesn't" (necessarily, because the
constraint violation that results could in general be at an arbitrary
distance from the point where a choice of parse has to be made). Or see
e.g. the disambiguation rule about enum type specifiers: there is an
explicit rule "If an enum type specifier is present, then the longest
possible sequence of tokens that can be interpreted as a specifier
qualifier list is interpreted as part of the enum type specifier." that
ensures that "enum e : long int;" interprets "long int" as the enum type
specifier, rather than "long" as the enum type specifier and "int" as
another type specifier in the sequence of declaration specifiers, even
though the latter parse would result in a constraint violation later.

Also, requiring unbounded lookahead to determine what kind of construct is
being parsed may be considered questionable for C. (If you have an
initializer starting .a.b.c.d.e, possibly with array element access as
well, those could all be designators or .a might be a reference to a
parameter of struct or union type and .b.c.d.e a sequence of references to
members within it and disambiguation under your rule would depend on
whether an '=' follows such an unbounded sequence.)

> - The type of a .identifier is always an incomplete type.
>
> - This prevents circular dependencies involving sizeof() or _Lengthof().

We have typeof as well, which can be applied to expressions with
incomplete type.

> - Shadowing rules apply.
>
> - This prevents ambiguity.

"Shadowing rules apply" isn't much of a specification. You need detailed
wording that would be added to 6.2.1 Scopes of identifiers (or equivalent
elsewhere) to make it clear exactly what scopes apply for identifiers
looked up using this construct.

> -
> void foo(struct bar { int x; char c[.x] } a, int x);
>
> Explanation:
> - Because of shadowing rules, [.x] refers to the struct member.

I really don't think standardizing VLAs-in-structures would be a good
idea. Certainly it would be a massive pain to specify meaningful
semantics for them and this outline doesn't even attempt to work through
the consequences of removing the rule that "If an identifier is declared
as having a variably modified type, it shall be an ordinary identifier (as
defined in 6.2.3), have no linkage, and have either block scope or
function prototype scope.".

The idea that .x as an expression might refer to either a member or a
parameter is also a massive change to the namespace rules, where at
present those are in completely different namespaces and so in any given
context a name only needs looking up as one or the other.

Again, proposals should be *minimal*. And even when they are, many issues
may well arise in practice (see the long list of constexpr issues in my
commit message for that C2x feature, for example, which I expect to turn
into multiple NB comments and at least two accompanying documents).

--
Joseph S. Myers
joseph@codesourcery.com