Okay, now after finishing reading all the discussion so far, I realized that we
are back to the previous pointer approach:
__builtin_get_counted_by (p->FAM)
Works as:
If (has_counted_by (p->FAM))
return &p->COUNT;
else
return (void *)0;
Then the user will use it as:
auto p = __builtin_get_counted_by(__p->FAM)
*_Generic(p, void*: &(int){}, default: p) = COUNT;
The major reason for back to the previous pointer approach is (from Martin):
"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 think that this is reasonable.
Then, let’s keep the previous pointer approach.
I will make sure the above _Generic approach work as well from the user’s side
first.
Let me know if you have other opinions.
Thanks a lot!
Qing
> On Sep 8, 2024, at 06:07, 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.
>
>
>>> 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
>
>
>
>
>
