Am Mittwoch, dem 22.01.2025 um 17:30 +0100 schrieb Michael Matz:
> Hello,
>
> On Wed, 22 Jan 2025, Martin Uecker wrote:
>
> > > > In .y[1][3].z after .y you can decide whether y is a member of the
> > > > struct being initialized. If it is, it is a designator and if not
> > > > it must be an expression.
> > >
> > > If y is not a member it must be an expression, true. But if it's a
> > > member
> > > you don't know, it may be a designation or an expression.
> >
> > In an initializer I know all the members.
>
> My sentence was ambiguous :-) Trying again: When it's a member, and you
> know it's a member, then you still don't know if it's going to be a
> designation or an expression. It can be both.
I guess this depends on what you mean by "it can be". The rule would simply
be that it is not an expression. The rationale is the following:
If it is inside the initializer of a structure and references a member of the
same structure, then it can not simultaneously be inside the argument to a
counted_by attribute used in the declaration of this structure (which at this
time has already been parsed completely). So there is no reason to allow it
be interpreted as an expression and the rule I proposed would therefor simply
state that it then is not an expression.
struct {
int n;
int *buf [[counted_by(.n)]]; // this n is in a counted_by
} x = { .n }; // this n can not be in counted_by for the same struct
If we allowed this to be interpreted as an expression, then you could use
it to reference a member during initialization, e.g.
struct { int y; int x; } a = { .y = 1, .x = .y };
but this would be another extension unrelated to counted_by, which I did
not intend to suggest.
There are other possibilities for disambiguation, we could also simply state
that in initializers at the syntatic position where a designator is allowed,
it is always a designator and not expression, and it then does not reference
a member of the structure being initialized, it is an error. Maybe this is
even preferable.
I would like to mention that what clang currently has in a prototype uses a
mechnanism called "delayed parsing" which is essentially infinite lookahead
(in addition to being confusing and incoherent with C language rules). So
IMHO we need something better.
My proposal for the moment would be to only allow very restricted syntactic
forms, and not generic expressions, side stepping all these issues.
Martin
>
>
> Ciao,
> Michael.
