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. > 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