On Tue, Apr 15, 2025 at 5:50 AM Michael Matz <m...@suse.de> wrote:
>
> 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.
>
All of this horribleness is because of the insistence of allowing for
primary expressions in the attributes, which I find to be a horrible
idea. Arguing that delayed parsing is "tolerable" in one instance but
not in another is a bit specious, given that the expressions we allow
are supposed to be "simple" (for some definition of simple), it should
only require doing that tolerable parsing a couple more times. (As
I've mentioned before, it would be so much better to place the
expression into a function.) Even the compromise we've discussed here
wouldn't fix all of our issues (see the problem I pointed out with
macro expansions).
Anyway, I withdraw my suggestion.
-bw
