The Linux kernel makes heavy use of GCC extensions, like statement expressions (https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Statement-Exprs...), __builtin_constant_p (https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Other-Builtins....), and GCC-style inline assembly. Since this means the kernel can only be compiled by gcc (or compilers which try to mimic gcc like clang, which pretends to be gcc 4.2.1), it makes sense to treat GCC (actually "the C89 standard plus GCC extensions") as the standard.

> it makes sense to treat GCC (actually "the C89 standard plus GCC extensions") as the standard.

While that might have been the case, this announcement says that one of the many reasons to stop using VLAs is to allow the kernel to be compiled with clang. The announcement reads like being able to compile the kernel with other compilers is a very desirable property, that has taken many years of hard work to achieve due to the incorrect assumption that "GCC is the C standard".

So while that assumption might have made sense back then, it does not appear to make sense now. If you treat one compiler as "the standard", chances are that that's the only compiler that you will ever be able to use. That's a bad strategic decision for a big project like the Linux kernel.

The C standard covers a lot of details and cases that the kernel doesn't need to worry about. That makes the C standard a lot more restricted and constrained. GNUC has some convenient features and extensions because it makes assumptions not guaranteed by the C standard that happen to work for all the platforms that Linux cares about, and also, not beeing driven by a comittee, it can generally iterate and improve the language in a more agressive and fast way.

Use of the language creates standards. Not the other way around.

So it's just the question of who is active on the committee.

Wrt C, unfortunately I believe there was a period where the standard was dictated by people who had no interest of even supporting previous versions of the standard.

That's a nice rule of thumb, and like many other good rules of thumb it has an opposite: Don't even try to write code you won't be able to test.

Both of those have good reasons, following them makes sense, and if you're at all lucky there's no conflict.