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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/>

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux