> On Jan 22, 2025, at 11:22, Martin Uecker <uec...@tugraz.at> wrote:
>
>
> Hello Michael,
>
> Am Mittwoch, dem 22.01.2025 um 16:54 +0100 schrieb Michael Matz:
>> On Wed, 22 Jan 2025, Martin Uecker wrote:
>>
>>>>> So you do not need to look further. But maybe I am missing something
>>>>> else.
>>>>
>>>> Like ...
>>>>
>>>>>> Note further that you may have '{ .y[1][3].z }', which is still not a
>>>>>> designation, but an expression under your proposal, whereas
>>>>>> '{ .y[1][3].z = 1 }' would remain a designation. This shows that you
>>>>>> now need arbitrary look-ahead to disambiguate the two. A Very Bad Idea.
>>>>
>>>> ... this?
>>>
>>> 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.
I am not familiar with the parser, so, I am a little confused about the
following:
Suppose we have:
struct foo {
int z;
float f;
}
struct bar {
char *array __attribute__ ((counted_by (.y[1][3].z + 4)));
struct foo y[5][10];
}
So, in the above, when parsing the above expression inside counted_by, can the
current parser be easily to be extended to parse it?
thanks.
Qing
>
> Martin
>
>
