Am Freitag, dem 04.04.2025 um 15:22 +0000 schrieb Qing Zhao:
> Hi, Michael,
>
> Thanks a lot for raising these questions for the parser implementation of the
> new syntax.
>
> I started thinking about how to implement this new syntax inside counted_by
> attriubte
> In GCC C FE. Since I have very little experience with any parser, I do want
> to know
> any potential implementation issues in GCC C FE with the new syntax.
>
> Based on your examples below, there is an example coming to my mind that is a
> little
> tricky:
>
> A:
> constexpr int len = 20;
> struct s {
> int len;
> int *buf __attribute__ ((counted_by (len))); // this continues to be member
> ‘len’, not global ‘len'
> };
>
> B:
> constexpr int len = 20;
> struct s {
> int len;
> int *buf __attribute__ ((counted_by (len+0))); //this is an expression ,
> ‘len' refers to the global;
> };
>
> When the parser is parsing the first identifier “len” inside the counted_by
> attribute, it cannot decide
> which syntax to use yet, it must look ahead at least one more word to decide,
> is this okay for the
> current C parser?
This is ok. But I wonder whether we should not require the second
form to have two arguments, and where the first is just empty if you do
not declare a member. Or maybe use two attribute names.
It is not just the parser, it is also the human reader who should be
able to clearly distinguish this (which is why I still prefer
designators syntax because this makes it perfectly clear).
struct s {
int len;
int *buf __attribute__ ((counted_by (;len+0)));
};
Martin
>
> Thanks.
>
> Qing
>
> > On Apr 4, 2025, at 09:21, Michael Matz <[email protected]> wrote:
> >
> > Hello,
> >
> > On Fri, 4 Apr 2025, Bill Wendling wrote:
> >
> > > > > I don’t have strong preference here. As mentioned by Jacub in a
> > > > > previous email, these two syntaxes can be distinguished by the
> > > > > number
> > > > > of arguments of the attribute.
> > > > >
> > > > > So for GCC, there should be no issue with either old name of a new
> > > > > name.
> > > > > However, I am not sure about CLANG. (Considering the complication
> > > > > with APPLE’s implementation)
> > >
> > > I also don't have a strong opinion on whether we should add new
> > > '*_expr' attributes. It's pretty easy to determine a single identifier
> > > from a more complex expression, so it's probably okay to use the
> > > current name. (I think that's what Apple has been doing internally.)
> >
> > Differentiating 'identifier' from 'decl' is easy (is first token a type?
> > -> decl), but 'lone-ident' from 'assignment-expression' requires some
> > look-ahead. It also always introduces the fun with useless
> > parentheses: is "(a)" a lone identifier or not? (Normally it's not).
> >
> > So, your current proposal (lone-ident or declaration) is good, from a
> > parsing perspective. But anything that somewhat merges lone-ident and
> > anything in the general assignment-expression syntax tree requires head
> > scratching, depending on parser implementation.
> >
> > > My initial thought is that you'd have something like this:
> > >
> > > struct Y {
> > > int n;
> > > };
> > >
> > > struct Z {
> > > int *ints __attrbiute__((counted_by(struct Y y; y.n)));
> > > struct Y y;
> > > };
> > >
> > > And it should "just work." I'm not sure if there's an issue with this
> > > though.
> >
> > I think it would just work in your proposal, yes. What about the typical
> > expr-vs-decl woes:
> >
> > typedef int TY;
> > struct Z {
> > int TY;
> > int *ints __attribute__((counted_by(TY))); // type or lone-ident?
> > };
> >
> > when the parser sees the 'TY' token in counted_by (without consuming it):
> > does it go your first (lone-ident) or your second (decl) branch? (Of
> > course the second would lead to a syntax error, but we don't know yet,
> > we've seen the TY token and know that it could refer to a type).
> >
> > The normal thing a parser would do is to go the second route (and lead to
> > syntax error). It shouldn't go the first route (lone-ident), as otherwise
> > you again have a confusion with:
> >
> > typedef int TY;
> > struct Z1 {
> > int *ints __attribute__((counted_by(TY))); // can only be type
> > int TY;
> > };
> >
> > which clearly is a syntax error. (Trying to avoid going the decl route
> > would also need another look-ahead)
> >
> > Anyway, I think your current proposal as-is (lone-ident | decl+expression)
> > is workable.
> >
> >
> > Ciao,
> > Michael.
>
>
