On Sun, Sep 8, 2024 at 3:07 AM Martin Uecker <ma.uec...@gmail.com> wrote:
>
> 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.
>
Oh! I missed that reply. Sorry about that. If they're open to
returning pointers all the better!
> > > 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.
>
I agree.
-bw
