On Fri, Jan 17, 2025 at 3:14 PM Joseph Myers <josmy...@redhat.com> 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.)
> - 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.
>
I re-opened the discussion on the LLVM discourse page. There wasn't a
lot of pushback when it was first brought up, so I suspect that people
will be generally amenable to it.
https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-c-fbounds-safety/70854/131?u=gwelymernans
-bw
> --
> Joseph S. Myers
> josmy...@redhat.com
