I find it ironic in that C++ has the correct solution to this problem. If you need type-pruning, use reinterpret_cast<foo>(bar). Done and done. Ironic, because Linus's weapon of choice (C... or more specifically, GCC's particular implementation of C) would require far more expertise to use correctly.<p>Lets break it down.<p>In C, type-punning is NOT part of the language. Its technically "undefined behavior". There's an expectation that when you do:<p><pre><code> short foo[2] = {1, 2} ;
*(int*)foo = 0x12345678;
assert(foo[0] == 0x5678 && foo[1] == 0x1234);
</code></pre>
A little-endian machine will pass this assert. But this isn't guaranteed by the C standard! This is "undefined behavior". The C-standard allows a C compiler to assume that foo[0] and foo[1] are still == to 1 and 2 respectively. Which would cause the assert to fail. In GCC -O2 or -O3, this may happen, depending on how registers get mapped to the variables. (The canonical memory location changes, but should registers be updated when optimizations are enabled??)<p>When an optimizer can assume, and when it can't assume, "aliasing" is very much an undefined behavior within the C language.<p>-------------<p>In effect, Linus knows GCC inside and out. GCC guarantees that unions will ALWAYS work for this aliasing problem. But this requires knowledge above and beyond the C Standard.<p>Linus may be "hating" and "criticizing" the standard in this case. And I guess there's certainly a gap. But the general expectation that everyone knows the intricacies of GCC to properly understand the kernel code is misplaced IMO, and goes back to "Angry Linus yells at random dev unnecessarily" territory for me.<p>And instead of simply explaining this VERY simple fact (although super-obscure) that GCC makes unions safe against aliasing issues at the compiler level... Linus yells at the dev. Not fair IMO.