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.)
- 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.
--
Joseph S. Myers
[email protected]
