On Fri, Apr 4, 2025, 12:23 PM Qing Zhao <qing.z...@oracle.com> wrote:
>
>
> > On Apr 4, 2025, at 13:09, Martin Uecker <uec...@tugraz.at> wrote:
> >
> > Am Freitag, dem 04.04.2025 um 18:51 +0200 schrieb Michael Matz:
> >> Hello,
> >>
> >> On Fri, 4 Apr 2025, Qing Zhao wrote:
> >>
> >>> So, a different attribute name “counted_by_exp” might be better?
> >>
> >> I would prefer Martins empty-decl idea to that: "counted_by(;len+0)"
> >> (looks up 'len' normally, i.e. doesn't look into current struct). It
> >> would naturally fit the either decl+expr or lone-ident parse.
> >> It may look weird but empty declarations are okayish IMHO.
> >>
> >> But overall: I just don't know, it all looks a bit unsexy, there only
> seem
> >> to be rocks and hard places :)
> >
> > I would not worry about this case too much, because I do expect this
> > to be a common use case anyway. That it looks strange may even be
> > an advantage here, as it alerts the reader that this is unusual.
>
> This is an interesting point and also a good point. -:)
>
> The other thought that bother me a little bit is:
>
> For the same attribute, counted_by, is it strange to have two different
> looking up rules
> depending on the different number of arguments?l
>
Sorry for the HTML. On my phone.
I think adding a ';' isn't the best option. It's too easy to overlook when
reading the attribute and forget when writing the attribute. Using a
separate attribute name is much cleaner, IMO. Then again, I've been wrong
before. :-)
-bw
> Qing
> >
> > Martin
> >
> >>
> >>
> >> Ciao,
> >> Michael.
> >>
> >>>
> >>> Qing
> >>>
> >>>> On Apr 4, 2025, at 11:55, Michael Matz <m...@suse.de> wrote:
> >>>>
> >>>> Hello,
> >>>>
> >>>> On Fri, 4 Apr 2025, Qing Zhao wrote:
> >>>>
> >>>>> 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?
> >>>>
> >>>> As I understood Bills proposal (but see below) a full expression that
> >>>> isn't a lone identifier would always require the decl+expression
> syntax,
> >>>> so the above would lead to a syntax error and wouldn't require
> further
> >>>> look-ahead. ('len' doesn't introduce a type, hence it can't be
> decl+expr,
> >>>> hence it must be lone-ident, which then generates the syntax error on
> >>>> seeing '+', after having successfully looked up 'len' among
> >>>> the struct members).
> >>>>
> >>>> But I now realize that I may have misunderstood the proposal in the
> cace
> >>>> that the expression does not in fact contain references to any struct
> >>>> members, e.g.
> >>>>
> >>>> enum {FOO=42};
> >>>> struct s {
> >>>> int len;
> >>>> int *buf __attribute__((counted_by( /*???*/ FOO + 0))); // no use
> of len
> >>>> };
> >>>>
> >>>> The proposal doesn't specifically talk about this case. Clearly
> there is
> >>>> no need to locally declare anything (at ???), but that would have
> been the
> >>>> syntactic hint to differentiate between both branches in the
> proposal.
> >>>> So, ... hmm, that would seem to again introduce the ambiguity between
> >>>> 'lone-ident' and 'expression'. I'm not sure how Bill wants to handle
> >>>> that. One could requre a useless dummy declaration, but that would
> be
> >>>> meh.
> >>>>
> >>>>
> >>>> Ciao,
> >>>> Michael.
>
>
>
