Hello,
On Mon, 14 Apr 2025, Bill Wendling wrote:
> Now, I don't think this will be necessarily confusing to the
> programmer, but it's inconsistent. In other words, either 'counted_by'
> *must* forward declare the in-structure identifier or neither must.
If that's your concern then both should require it, instead of neither,
because ...
> 1. The syntax needs to be unambiguous.
> 2. Identifier lookup must be consistent between the two attribute forms.
> 3. The common use case should take the least amount of code to write.
> (More of a "nice to have".)
>
> Therefore, I suggest the following rules, that are more-or-less the
> reverse of the current proposal's rules:
>
> - All untagged identifiers are assumed to be within the structure. If
> they aren't found in the struct, it's an error.
> - All globals (i.e. identifiers not in the struct) must be referenced
> via a special tag or a builtin (e.g. __builtin_global_ref()). The tag
> or builtin follow current scoping rules---i.e. it may pick up a shadow
> variable rather than the global.
... with that proposal, you're basically reverting back to the hack to
replicate the whole assignment-expression syntax tree down to
primary-expr just so that you can apply a special lookup rule for
the identifier->primary-expr production. And you're using that replicated
assignment-expression tree in just a single attribute. And to top it off
you then introduce another syntactic production to revert to the normal
lookup behaviour within the to-be-determined tag/builtin.
As discussed multiple times in this thread this syntax isn't unambiguous
(you need special wording and a new scoping rule on top of the syntax to
make it all unambigous). Even worse, under your new proposal this ...
> struct A {
> int *buf __counted_by(len); // 'len' *must* be in the struct.
> int len;
> };
... means that we would have to implement general delayed parsing for
expressions in C parsers. Doing that for a lone-ident only was always
meh, but somewhat acceptable. But the above means we have to do that
always for the new expr-within-counted syntax tree. That may be working
fantastically if you're hacking all this into a c++ parser, but for other
parsers that is something completely new.
I don't think this new proposal is new, it seems to be just the original
Apple variant at its core, with new non-general scoping rule, weird escape
mechanism, delayed parsing and basically everything that caused this long
thread.
Ciao,
Michael.
