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 hope the kernel community understands this.
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
>
