> On Mar 26, 2025, at 1:52 PM, Yeoul Na <yeoul...@apple.com> wrote:
> 
> Hi Joseph,
> 
>> On Mar 26, 2025, at 12:07 PM, Joseph Myers <josmy...@redhat.com> wrote:
>> 
>> On Wed, 26 Mar 2025, Yeoul Na wrote:
>> 
>>> Hi all,
>>> 
>>> Thanks for all the discussions.
>>> 
>>> I posted the design rationale for our current approach in 
>>> https://discourse.llvm.org/t/rfc-forward-referencing-a-struct-member-within-bounds-annotations/85510.
>>>  
>>> This clarifies some of the questions that are asked in this thread. The 
>>> document also proposes diagnostics to mitigate potential ambiguity, and 
>>> propose new builtins that can be used as a suppression and 
>>> disambiguation mechanism.
>> 
>> That doesn't say anything about the handling of ambiguity between 
>> structure members and typedef names.
>> 
>> typedef char T;
>> 
>> struct foo {
>> int T;
>> int U;
>> int *__counted_by((T)+U) buf;
>> };
>> 
>> Is T interpreted as a typedef name inside __counted_by?  Or does even the 
>> interpretation of which identifiers are typedef names and which are 
>> expressions depend on membership of the structure?
>> 
>> -- 
>> Joseph S. Myers
>> josmy...@redhat.com
>> 
> 
> Inside `__counted_by` will see the struct scope, so a typedef will also be 
> shadowed by a member declaration. Thus, `T` would be interpreted as a member 
> inside `__counted_by`.

We can also add diagnostics in such a situation where the name conflicts with a 
typedef.


> Thanks,
> Yeoul

Reply via email to