[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 -- Kees Cook
