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

[Alejandro Colomar]

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

-- 
<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/bee54099/attachment.sig>