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

Alejandro Colomar
2022-11-12T12:34:50Z

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

Hi Joseph,

On 11/11/22 00:19, Joseph Myers wrote:
> On Thu, 10 Nov 2022, Martin Uecker via Gcc wrote:
>
>> One problem with WG14 papers is that people put in too much,
>> because the overhead is so high and the standard is not updated
>> very often. It would be better to build such feature more
>> incrementally, which could be done more easily with a compiler
>> extension. One could start supporting just [.x] but not more
>> complicated expressions.
>
> Even a compiler extension requires the level of detail of specification
> that you get with a WG14 paper (and the level of work on finding bugs in
> that specification), to avoid the problem we've had before with too many
> features added in GCC 2.x days where a poorly defined feature is "whatever
> the compiler accepts".
>
> If you use .x as the notation but don't limit it to [.x], you have a
> completely new ambiguity between ordinary identifiers and member names
>
> struct s { int a; };
> void f(int a, int b[((struct s) { .a = 1 }).a]);

Is it really ambiguous? Let's show some currently-valid code:

struct s {
int a;
};

struct t {
struct s s;
int a;
};

void f(void)
{
struct t x = {
.a = 1,
.s = {
.a = ((struct s) {.a = 1}).a,
},
};
}

It is ambiguous to a human reader, but that's a subjective thing, and of course
shadowing should be avoided by programmers. However, for a compiler, scoping
and syntax rules should be unambiguous, I think. In your code example, I
believe it is unambiguous that both '.a' refer to the struct member.

But maybe we're not considering more complex situations that might really be
ambiguous to the compiler, so a first round of supporting only [.a] would be a
good first implementation.

>
> where it's newly ambiguous whether ".a = 1" is an assignment to the
> expression ".a" or a use of a designated initializer.
>
> (I think that if you add any syntax for this, GNU VLA forward declarations
> are clearly to be preferred to inventing something new like [.x] which
> introduces its own problems.)
>

Cheers,

Alex