> 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.
>
> 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.
>
> 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.
Cheers,
Yeoul
