> On Jan 17, 2025, at 18:13, Joseph Myers <[email protected]> wrote:
>
> On Fri, 17 Jan 2025, Qing Zhao wrote:
>
>> struct fc_bulk {
>> ...
>> struct fs_bulk fs_bulk;
>> struct fc fcs[] __counted_by(fs_bulk.len);
>> };
>>
>> i.e, the “counted_by” field is in the inner structure of the current
>> structure of the FAM.
>> With the current syntax, it’s not easy to extend to support this.
>>
>> But with the designator syntax, it might be much easier to be extended to
>> support this.
>>
>> So, Kees and Bill, what’s your opinion on this? I think that it’s better to
>> have a consistent interface between GCC
>> and Clang.
>>
>> Joseph, what’s your opinion on this new syntax? Shall we support the
>> designator syntax for counted_by attribute?
>
> Designator syntax seems reasonable.
>
> I think basic C language design principles here include:
>
> * It should be unambiguous in a given context what name space an
> identifier is to be looked up in. (So you can have designator syntax
> where the identifier is always looked up as a member of the relevant
> struct, or use a plain identifier where the semantics are defined that
> way. But what would be a bad idea would be any attempt to automagically
> guess whether something that looks like an expression should be
> interpreted as an expression or with identifiers instead looked up as
> structure members. If you allow fs_bulk.len above, there should be no
> possibility of fs_bulk being an ordinary identifier (global variable etc.)
If we use the designator syntax for counted by, then the correct syntax for the
above should be:
struct fc_bulk {
…
struct fs_bulk fs_bulk;
struct fc fcs[] __counted_by(.fs_bulk.len);
};
> - the name lookup rules should mean it's always only looked up as a member
> of the current structure.)
>
> * Don't introduce something "like expression but with different name
> lookup rules". Designators aren't expressions and have limited syntax.
> It would be a bad idea to try to e.g. have something allowing arithmetic
> on designators. For example, don't allow __counted_by(.len1 + .len2)
> where len1 and len2 are both members, as that's inventing a complete new
> expression-like-but-not-expression syntactic construct.
So, even after we introduce the designator syntax for counted_by attribute,
arbitrary expressions as:
counted_by (.len1 + const)
counted_by (.len1 + .len2)
Still cannot be supported?
If not, how should we support simple expressions for counted_by attribute?
Thanks.
Qing
>
> --
> Joseph S. Myers
> [email protected]
