> On Jul 23, 2025, at 12:30 AM, Kees Cook <k...@kernel.org> wrote:
>
> On Wed, Jul 23, 2025 at 07:47:11AM +0200, Martin Uecker wrote:
>> IMHO there are enough reasons to reject delayed parsing
>> as bad design for C. We should work towards proper
>> language features that cleanly fit into the language,
>> instead of pushing the boundaries with macros.
>>
>> But this requires true collaboration, which can not
>> exist when one side is not able to compromise. What
>> happens next time there is a disagreement? Will clang
>> again try to force its decision on the rest of us?
>
> I can't speak for the Apple folks, but I do find this whole situation
> quite frustrating. I am disappointed that on this feature there has
> been very little visible movement by Apple to find common ground on
> the -fbounds-safety features. I think Bill has been proving out ways
> to solve expression handling that should appease both Clang and GCC,
> but those efforts keep hitting walls.
Thanks for your patience through this process. Our aim has always been to
design features that are both ergonomic and widely adoptable, so that they
don’t end up unused or obsolete. After many discussions within the compiler
communities, we concluded that seeking guidance from the standards committee
might be the only way to find real common ground.
In the meantime, I hoped we could still make progress by supporting the simple
identifier use cases, since both the Clang and GCC communities seem comfortable
with allowing __counted_by(id) at least. Since we were submitting a proposal to
the standard committee, I felt it was important to inform everyone, so no one
ends up building something that might be rejected shortly after development due
to incompatibility with the committee’s decisions.
I agree that this approach takes time, and I also recognize the need for a
compromise solution to address urgent cases. Now that the proposal has been
sent, I plan to spend more time actively working on a compromise solution as
well.
Out of curiosity, do you think focusing on simple identifier cases (which, as I
understand, are the majority in the Linux kernel as well) would allow us to
make meaningful progress for now? My assumption is that even such simple use
cases (e.g., __counted_by(field) on a pointer field) are yet to be widely
adopted across the Linux codebases, but I’d love to hear your perspective.
Yeoul
>
>> I hope the kernel community understands this.
>
> I do for sure. At the end of the day I'm a pragmatist, and I'm always
> hoping to find common ground or at least a workable solution with benefits
> that can outweigh any down sides. We seem to keep going in circles about
> finding a "least bad" option, though.
>
> How would GCC want to define the syntax for expressions here? I still
> think it should be possible to wire up something that matches it in
> Clang, even if it is a "redundant" syntax within Clang (i.e. Clang can
> support 2 way to handle expressions, GCC has 1, and Linux will use the
> common way).
>
> The two things I've seen proposed during all of these discussions that
> look like they should be workable are either:
>
> 1) making expression-using attributes _struct_ attributes, not struct
> _member_ attributes. (i.e. parsing of the struct has ended)
>
> 2) using a callback for expressions (no late parsing needed)
>
> I'm well aware that Apple's implementation will not do either of these,
> but I'm confident Clang can support the additional syntax -- it should
> be possible to provide both, especially since it would be a "GCC
> compatibility" issue. :)
>
> -Kees
>
> --
> Kees Cook
