Am Donnerstag, dem 27.03.2025 um 17:01 -0700 schrieb Bill Wendling via Gcc:
> On Tue, Mar 25, 2025 at 10:13 PM Martin Uecker <uec...@tugraz.at> wrote:
> > Am Dienstag, dem 25.03.2025 um 19:09 -0700 schrieb Bill Wendling:
> > > On Tue, Mar 18, 2025 at 3:04 PM Martin Uecker <uec...@tugraz.at> wrote:
> > > >
> >
> > >
> > > It seems clear that using "__self" is most likely going to be part of
> > > any solution we come up with. What we need to avoid is feature skew
> > > between GCC and Clang. It'll revert projects back into the "compiler
> > > war" days, which isn't beneficial to anyone. Is there a compromise
> > > that's acceptable for both GCC and Clang beyond adding "__self", but
> > > not requiring it?
> >
> > Having the syntax but not requiring it does not solve the problem,
> > because it would still require compilers to implement late parsing
> > (a problem for many C compilers).
> >
> > If we require __self__ now, this would allow us to move on while
> > leaving the door open to finding consensus later, e.g. after WG14
> > has considered it in the next meeting.
> >
> Do you have any thoughts, good or bad, on having a forward reference
> in the attribute? Something like:
>
> struct foo {
> int *buf __counted_by(short len; len); // refers to 'len' below
> short len;
> };
This would solve the parsing problem including the issue that we
could then parse complicated expressions where we need to know the
type of len during parsing. It also would make it possible to simple
apply existing parsers to the expression that follows.
So I would be happy ok with it.
Neverthless, in the context of a struct, I think one *could* allow
nicer syntax such as .len because on has to restrict the allowed
expressions anyway (to not run arbitrary code during member access),
so I think forward declarations are more powerful then what is
needed here. But they solve the problem and they still keep the
door open for using more succinct syntax later, so this is fine
with me.
Martin
