Am Mittwoch, dem 12.03.2025 um 16:58 +0000 schrieb Joseph Myers:
> On Wed, 12 Mar 2025, Martin Uecker wrote:
>
> > For a designator
> >
> > struct foo { int n; } a = { .n = 1 };
> >
> > we also refer to a member 'n' of an instance 'a' of a structure type.
> > The instance is simply implied by the context.
> >
> > For
> >
> > struct foo { int n; char *x __counted_by(.n) };
> >
> > is also refers to a member of an instance of the struct. The
> > instance is the 'a' which is later used in an expression 'a.x'
> > So the instance would again be implied by the context.
> >
> > So for me this makes perfect sense in both cases (and
> > for both C and C++)
>
> The main concern with the designator syntax is if you try to embed it in
> arbitrary expressions (that is, say that __counted_by takes an expression,
> but with an additional kind of primary-expression .IDENTIFIER that can be
> used as a sub-expression therein). The above is fine, but
>
> struct foo { int n; char *x __counted_by((struct bar){.n = 1}.n };
>
> leaves an ambiguity of whether ".n = 1" is a designated initializer in the
> struct bar compound literal, or an assignment expression where .n refers
> to the member of the struct foo for which the number of elements of x is
> being counted. Note that N3188 definitely does not allow .IDENTIFIER as
> part of an expression, only as an alternative to an expression in an array
> declarator.
My solution for this would be to simply state that in a position
in the grammar where a designator is allowed, this then has to be
parsed as a designator. So if struct bar has no member 'n' this
would be a syntax error.
Martin
>
