> 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
> <mailto: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.
>
This should be handled by diagnostics.
>
>>> 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
