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.

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.
> > 
> > 

Reply via email to