Hi Joseph, On 11/12/22 14:03, Joseph Myers wrote:
On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote: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:Well, I still don't know what the syntax addition you propose is. Is it postfix-expression : . identifier
I'll try to explain it in standardeese, but I'm not sure if I'll get it right, so I'll accompany it with plain English.
Maybe Martin can help.Since it's to be used as an rvalue, not as a lvalue, I guess a postfix-expression wouldn't be the right one.
(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.
Or it could match designation[opt] initializer, where ".a" is a designator. And as I've noted many times in discussions of C2x proposals on the WG14 reflector, if some sequence of tokens can match the syntax in more than one way, there always needs to be explicit normative text to disambiguate the intended parse - it's not enough that one parse might lead later to a violation of some other constraint (not that either parse leads to a constraint violation in this case). Or is the syntax array-declarator : direct-declarator [ . assignment-expression ]
Not good either. The '.' should prefix the identifier, not the expression. So, for example, you would have:
void *bsearch(const void key[.size], const void base[.size * .nmemb],
size_t nmemb, size_t size,
int (*compar)(const void [.size], const void [.size]));
That's taken from the current manual page from git HEAD. See 'base', which gets
its size from the multiplication of 'size' and 'nmemb'.
(with appropriate variants with static and type-qualifier-list and for array-abstract-declarator as well, and with different identifier interpretation rules inside the assignment-expression)? If so, then there are big problems parsing [ . ( a ) + ( b ) ], where 'a' is a typedef name in an outer scope, because the appropriate parse would depend on whether 'a' is shadowed by a parameter - unless of course you add appropriate wording like that present in some places about not being able to use this syntax to shadow a typedef name. Or is it just array-declarator : direct-declarator [ . identifier ]
For the initial implementation, it would be, I think.
which might avoid some of these problems at the expense of being less expressive?
Yes.
If you're proposing a C syntax addition, you always need to be clear about exactly what the new cases in the syntax would be, and how you resolve ambiguities with any other existing part of the syntax, how you interact with rules on scopes, namespaces and linkage of identifiers, etc.
Yeah, I'll try.I think that the complete feature would allow 'designator' to be used within unary-expression:
unary-expression: designatorSince sizeof(foo) is a unary-expression and you can't assign to it, I'm guessing that similar rules could be used for '.size'.
That would have the effect of allowing both features suggested by Martin: being able to used designators in both structures (as demonstrated in my last email) and function prototypes (as in the thing we're discussing).
I hope I got it right. I'm not used to lexical grammar so much. Cheers, Alex -- <http://www.alejandro-colomar.es/>
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
