On Tue, Jul 22, 2025 at 10:47 PM Martin Uecker <ma.uec...@gmail.com> 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.
You've mentioned one reason: the possibility that some context may somehow affect parsing, but haven't pointed out which context or how it would affect parsing. And as mentioned before, we're doing that already with the current implementation, but only on a small scale (single identifier). My question then is: what C context would affect how an expression is parsed so that it's semantic meaning is changed in some undesirable way? (There is some context that we *do* want changed, e.g. the full struct type should be defined.) I really don't want to work in hypotheticals with this. > 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'm as frustrated with the response as you are. However, despite the decision that was made far too early, the developers in charge of this feature *are* still willing to work with us. > I hope the kernel community understands this. I'm doubtful about this. :-( -bw > Martin > > Am Dienstag, dem 22.07.2025 um 21:23 -0700 schrieb Kees Cook: > > [Explicitly CCing Joseph since this thread[1] is about the C front-end] > > > > On Tue, Jul 22, 2025 at 09:01:35PM +0000, Qing Zhao wrote: > > > However, given the current situation, I also think that provide two > > > different interfaces from CLANG > > > and GCC might be the practical solution to this endless discussion. > > > > > > Can you explain a little bit on why “two versions will kill this feature > > > in the Linux kernel”? > > > > If the behavior or the syntax differs too greatly between Clang and GCC, > > the kernel will have to effectively choose between them. Supporting very > > different syntax may be technically possible in Linux, but the developer > > community there won't tolerate redundant nor intrusive macros to achieve > > dual support. > > > > I've already pushed the boundaries with some complicated struct macros > > (struct_group[2], DECLARE_FLEX_ARRAY[3], etc) but I share the concern > > about a totally split solution. Given a split, Linux would likely choose > > the Clang feature set in this case, as Clang is supporting other security > > features that GCC currently lacks (i.e. KCFI support[4], randomized > > structure layouts[5], stack depth tracing callbacks[6], and overflow > > behavior types[7]). > > > > Qing and Bill have been working very hard (and successfully) to keep > > much of the security feature parity on track between GCC and Clang, > > so I'm really hoping we can resolve this one too, but I see how tricky > > it is. > > > > And just to restate the problem (probaby mostly for myself), as I > > understand it, a "simple" delayed parsing already exists as part of Qing's > > series[8] (single-member counted_by for pointers), but anything complex > > (i.e. expressions for counted_by, sized_by, etc) will need something > > like what Bill has proposed[1]. There is also the function callback > > proposal[9], but that hasn't quite taken off with either compiler. > > > > -Kees > > > > [1] https://gcc.gnu.org/pipermail/gcc-patches/2025-July/690024.html > > [2] > > https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/stddef.h?h=v6.15#n18 > > [3] > > https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/stddef.h?h=v6.15#n39 > > [4] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107048 > > https://clang.llvm.org/docs/ControlFlowIntegrity.html#fsanitize-kcfi > > [5] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116457 > > > > https://clang.llvm.org/docs/AttributeReference.html#randomize-layout-no-randomize-layout > > [6] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121222 > > https://clang.llvm.org/docs/SanitizerCoverage.html#tracing-stack-depth > > [7] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116193 > > https://github.com/llvm/llvm-project/pull/148914 > > [8] https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689754.html > > [9] > > https://discourse.llvm.org/t/rfc-bounds-safety-in-c-syntax-compatibility-with-gcc/85885/39 > > >
