> On Mar 12, 2025, at 18:46, Yeoul Na <yeoul...@apple.com> wrote:
>
>
>
>> On Mar 12, 2025, at 3:40 PM, Bill Wendling <isanb...@gmail.com> wrote:
>>
>> On Wed, Mar 12, 2025 at 3:28 PM Yeoul Na <yeoul...@apple.com> wrote:
>>>> On Mar 12, 2025, at 2:51 PM, John McCall <rjmcc...@apple.com> wrote:
>>>>
>>>> On 12 Mar 2025, at 16:02, Bill Wendling wrote:
>>>>> Qing pointed out in four lines of code how there are two different
>>>>> token resolution rules being used: one which is reliant upon C's
>>>>> current scoping rules and the other which requires a completely new
>>>>> scoping rule. This is no longer a question about what a programmer is
>>>>> most likely to infer what is meant or if the documentation makes it
>>>>> clear what's happening or any other ambiguous issues that me and
>>>>> others put forth before. This is a serious problem. There are
>>>>> essentially two options we have:
>>>>>
>>>>> 1. Create a proposal to the C standards committee adding an "instance
>>>>> scope" into the language and use that for the feature, or
>>>>> 2. Find some other way, which doesn't require modifying the base language.
>>>>
>>>> We are actually planning to write a paper for the C committee, so if
>>>> you’re willing to wait for that, perhaps that’s the right path forward.
>>>>
>>>> John.
>>>
>>> Let me clarify. We never proposed to change the base language. Please check
>>> my earlier response to Qing:
>>>
>>>> Yes, I read it and thanks again for writing it up! One clarification
>>>> related to that is -fbounds-safety never proposed to change the existing C
>>>> behavior. It’s adding an instantiation scope for the bounds annotations
>>>> only so members can be accessed within that context, this is similar in a
>>>> way to your __self proposal in that it’s introducing an instantiation
>>>> scope so that it can be only accessed through the __self syntax.
>>
>> I don't think any of us intended to change the base language, but from
>> my reading of Qing's writeup we are. And I don't agree that __self is
>> also adding an instance scope. It's a way to reference the current
>> object, similar to 'this' in C++. Any reference to members within that
>> object must be resolved by reference: __self.member, etc. The members
>> aren't resolved by resorting to a scoping rule.
>
> I don’t think so, we are changing only if we also changed how VLAs are
> handled. Qing also wrote this:
>
>> You can argue to only add the new variable scope for counted_by attribute,
>> not for VLA, then how to handle the following case:
>>
>> [opc@qinzhao~]$ cat t8.c
>> void boo (int k)
>> {
>> const int n = 10; // a local variable n
>> struct foo {
>> int n; // a member variable n
>> int a[n + 10]; // for VLA, this n refers to the local variable n.
>> char *b __attribute__ ((counted_by(n + 10)))
>> // for counted_by, this n refers to the member variable n.
>> };
>> }
>>
>> This will be a disaster.
>>
>
The above example showed a very clear conflict situation between the default C
scoping rules
(Only global scope and local scope) between the additional instance scope
introduced by the
current counted_by syntax, which really is a disaster that we should avoid.
Both GCC and CLANG made a mistake in the beginning when design the syntax for
counted_by,
It’s still not too late to correct this.
> This should be handled by diagnostics.
No, diagnostic is not the right way to correct this design mistake, I think we
should change the syntax
To avoid such confusion.
Qing
>
>
>>
>>>> Then, the question would be potential confusions caused by inconsistency
>>>> with how array sizes are handled. However, trying to make it consistent
>>>> with arrays could actually make the counted_by itself more error-prone and
>>>> confusing because they are inherently different: arrays can never
>>>> reference members while counted_by should be able to. I’ll share our full
>>>> reasoning with examples in the RFC that I’ll post soon.
>>
>> This is exactly why we're suggesting the '__self' (or maybe another
>> idea). :-) It removes all inconsistencies without adding a new scoping
>> rule to the language. However, as I said in my last email, we're past
>> worrying about user confusion because we really shouldn't change the
>> base language (adding a new scoping rule) in ways that haven't yet
>> been approved by the standards committee.
>
> And yes, again, I don’t oppose to introducing ‘__self’ or some other scope
> specifiers so that you can write it more clearly when you should. But it
> doesn’t have to be the default way of writing to most of the code where we
> don’t have such obscure ambiguous code.
>
> Cheers,
> Yeoul
>
>
>>
>>>> And the confusing code like below should be able to be handled by
>>>> diagnostics. The code like this is already confusing to readers and
>>>> writers of this code no matter which approach we will take and how clear
>>>> it would be for the compiler and the standard.
>>>>
>>>> void boo (int k)
>>>> {
>>>> const int n = 10; // a local variable n
>>>> struct foo {
>>>> int n; // a member variable n
>>>> int a[n + 10]; // for VLA, this n refers to the local variable n.
>>>> char *b __attribute__ ((counted_by(n + 10)))
>>>> // for counted_by, this n refers to the member variable n.
>>>> };
>>>> }
>>>
>>>
>>>
>>> We will share our RFC to this audiences by (hopefully) this week about how
>>> we design the bounds extension without changing the base language. The
>>> target audiences are people in this thread and compiler implementers.
>>>
>>> And separately we are also working on proposals targeting the C committee,
>>> unlike RFC for compiler changes, this may include some suggestions to
>>> change the base C language as well.
>>
>> Thanks,
>> -bw
>
>
