Am Freitag, dem 17.01.2025 um 15:34 -0800 schrieb Bill Wendling:
> 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
Thank you!
Martin
