Am Sonntag, dem 08.09.2024 um 02:09 -0700 schrieb Bill Wendling:
> On Fri, Sep 6, 2024 at 10:50 PM Martin Uecker <ma.uec...@gmail.com> wrote:
> >
> > Am Freitag, dem 06.09.2024 um 13:59 -0700 schrieb Bill Wendling:
> > > On Fri, Sep 6, 2024 at 12:32 PM Martin Uecker <ma.uec...@gmail.com> wrote:
> > > > > > >
...
> > > >
> > > > My recommendation would be not to change __builtin_choose_expr.
> > > >
> > > > The design where __builtin_get_counted_by returns a null
> > > > pointer constant (void*)0 seems good. Most users will
> > > > get an error which I think is what we want and for those
> > > > that want it to work even if the attribute is not there, the
> > > > following code seems perfectly acceptable to me:
> > > >
> > > > auto p = __builtin_get_counted_by(__p->FAM)
> > > > *_Generic(p, void*: &(int){}, default: p) = 1;
> > > >
> > > >
> > > > Kees also seemed happy with it. And if I understood it correctly,
> > > > also Clang's bounds checking people can work with this.
> > > >
> > > The problem with this is explained in the Clang RFC [1]. Apple's team
> > > rejects taking the address of the 'counter' field when using
> > > -fbounds-safety. They suggested this as an alternative:
> > >
> > > __builtin_bounds_attr_arg(ptr->FAM) = COUNT;
> > >
> > > The __builtin_bounds_attr_arg(ptr->FAM) is replaced by an L-value to
> > > the 'ptr->count' field during SEMA, and life goes on as normal. There
> > > are a few reasons for this:
> > >
> > > 1. They want to track the relationship between the FAM and the
> > > counter so that one isn't modified without the other being modified.
> > > Allowing the address to be taken makes that check vastly harder.
> >
> > In the thread it is pointed out that returning a pointer works
> > too, and they would simply restrict passing the pointer elsewhere.
> >
> It's in rapidsna's initial reply titled "Taking the address of a count
> variable is forbidden":
>
>
> https://discourse.llvm.org/t/rfc-introducing-new-clang-builtin-builtin-get-counted-by/80836/2
>
> I didn't see her retreating from that idea.
The initial proposal already has this as "Alternative Design"
and then there is this response to my comment:
https://discourse.llvm.org/t/rfc-introducing-new-clang-builtin-builtin-get-counted-by/80836/27
which seems to imply that she is open to this idea.
> > I can't see "Apple's team rejects" and "vastly harder" at the
> > moment.
> >
> > >
> > > 2. Apple's implementation supports expressions in the '__counted_by'
> > > attribute, thus the 'count' may be an R-value that can't have its
> > > address taken.
> > >
> > > [1]
> > > https://discourse.llvm.org/t/rfc-introducing-new-clang-builtin-builtin-get-counted-by/80836/
> >
> > Yes, this would be a limitation.
> >
> And not one that I'm particularly excited about (allowing for (nearly)
> arbitrary expressions in the 'counted_by' attribute that is).
And I do not see how returning an r-value can work with the
intended use case for __builtin_get_counted_by() anyway, because
this would break assignments.
So I do not see any issue against returning a pointer and (void*)0
when there is no attribute and if the expression is a r-value.
Martin
