Did you actually read what he wrote? He agrees that's what the standard says, thus the standard is not workable in reality, so he goes with GCC's (defined in documentation) implementation. It doesn't "just happen to work" in GCC, it deliberately works, and GCC is the only compiler the core kernel devs care about (see ASM goto).

Sure. And that's a terrible reason.

First, he's binding Linux to gcc forever. I've made that mistake and let me tell you, it's a mistake with surprisingly few benefits. A couple of asms and gccisms? Easily replaced.

Second, it is an error to call gcc's behavior "defined in documentation" as if that means it's okay to use. It's just a flag to support obsolete code. Long-term, the assumption that gcc will retain flags to support antique code is optimistic.

Third, "the standard is not workable in reality" is simply wrong. I work on low-level systems. I somehow manage to work with devices and networks on a day-to-day basis without relying on this.

Ultimately it comes down to this: Linus put his faith in something which was explicitly removed from C 30 years ago. The writing has been on the wall for about 10 years now[1]: Good optimizers are going to do away with this mis-feature. Time to start adapting to reality.

[1] http://blog.qt.io/blog/2011/06/10/type-punning-and-strict-al...

> Second, it is an error to call gcc's behavior "defined in documentation" as if that means it's okay to use. It's just a flag to support obsolete code. Long-term, the assumption that gcc will retain flags to support antique code is optimistic.

Type punning through a union works on GCC without -fno-strict-aliasing, and is documented in multiple places. Among others, it's suggested as an alternative to fix code broken under strict aliasing here: https://gcc.gnu.org/bugs/#nonbugs.

It's also relatively safe to assume that GCC will continue to be able to compile the Linux kernel for the indefinite future, since it would be very high profile, cause a ton of drama, and result in many people to moving away from GCC (including contributors). It seems very unlikely to be a smart decision.

(That's not to say lower profile projects than the linux kernel should rely on this. Using memcpy/memmove is just as fast and that much more difficult).

The difference is that the code you wrote actually is dumb, but relying on union aliasing is not. :) A behavior doesn't need to be defined by the spec as long as it is defined by the implementation (gcc) you are targeting.

The code I wrote was dumb... and yet Stroustroup repeatedly made a variant of the mistake in the "C++ Programming Language." Turns out that the use of operator<< in iostreams is problematic.

It's gcc defined behavior. Not the BS (his words) C standard behavior.