On Fri, Apr 4, 2025 at 8:55 AM 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.
>
With the current proposal, the 'FOO' is assumed to be a global (or at
least not in the struct), because the forward declaration is for
struct fields. (That's if I've correctly understood what was suggested
in the thread. :-) If this is problematic, we can come up with
something a bit better.
-bw
