https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #31 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #29)
> > however, I think that both the new attribute and the new C syntax extension
> > should support the similar user interface. We might need to decide on this
> > first.
>
> I think there are some fundamental differences: In one
> case the size is encoded into the type and in the other
> it is just an annotation that can be ignored.
Yes, understood.
I might not make myself clear in the previous message. what I mean by the "the
similar user interfaces" is:
both might support the following:
1. a declared variable as the size:
**C syntax extension:
unsigned int length;
struct object {
int others;
char flex[length];
}
**corresponding attribute:
unsigned int length;
struct object {
int others;
char flex[] __attribute__((__element_count__(length)));
}
2. a declared field of the same structure as the size:
**C syntax extension:
struct object {
unsigned int length;
char flex[.length];
}
**corresponding attribute:
struct object {
unsigned int length;
char flex[] __attribute__((__element_count__(.length)));
}
3. expressions including declared variables and declared fields of the same
structure as the size:
**C syntax extension:
unsigned int item;
struct object {
unsigned int ratio;
char flex[item * .ratio];
}
**corresponding attribute:
unsigned int item;
struct object {
unsigned int ratio;
char flex[] __attribute__((__element_count__(item * .ratio)));
}
Not sure on the following case:
4. a declared field of the containing structure as the size:
**C syntax extension:
struct object {
unsigned int length;
struct inner {
...
int flex[..length];
};
}
**corresponding attribute:
struct object {
unsigned int length;
struct inner {
...
char flex[] __attribute__((__element_count__(..length)));
}
}
what else from the user's point of view?
>
> >
> > right now, the user interface we cannot agreed on is:
> >
> > whether we should support the following nested annotation (either with
> > attribute or with the C syntax extension):
> >
> > struct object {
> > ...
> > unsigned int items;
> > ...
> > struct inner {
> > ...
> > int flex[];
> > };
> > } *ptr;
> >
> I am fine with supporting it, but one needs to decide
> on the semantics in the case where inner is not accessed
> via the outer struct.
Yes, that's right.
