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.
