> On Apr 4, 2025, at 12:51, Michael Matz <m...@suse.de> wrote:
>
> 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.
Fine with me.
>
> But overall: I just don't know, it all looks a bit unsexy, there only seem
> to be rocks and hard places :)
Same feeling -:)
It’s a compromised approach anyway...
Qing
>
>
> 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.
>>
>>
