> On Apr 4, 2025, at 13:09, Martin Uecker <uec...@tugraz.at> wrote:
>
> Am Freitag, dem 04.04.2025 um 18:51 +0200 schrieb Michael Matz:
>> 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.
>>
>> But overall: I just don't know, it all looks a bit unsexy, there only seem
>> to be rocks and hard places :)
>
> I would not worry about this case too much, because I do expect this
> to be a common use case anyway. That it looks strange may even be
> an advantage here, as it alerts the reader that this is unusual.
This is an interesting point and also a good point. -:)
The other thought that bother me a little bit is:
For the same attribute, counted_by, is it strange to have two different looking
up rules
depending on the different number of arguments?
Qing
>
> Martin
>
>>
>>
>> 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.
