He's probably right, but he expresses his ideas so poorly that he turns straightforward points into drama, I think intentionally. He doesn't just not give a shit about standards (probably healthy), but also what any of his audience thinks about his ideas (probably not so much).<p>At this point, his flailing supposed anger is really just schtick. He deploys it so casually you just assume it isn't serious. Ironically, he could convey his contempt for standards, or for people who adhere to them slavishly, far more effectively if he simply wrote in a civil tone, rather than continuing to try to affect his Andrew Dice Clay of Programming persona.
Before anyone flips out, he actually merged the code:
<a href="https://lkml.org/lkml/2018/6/5/774" rel="nofollow">https://lkml.org/lkml/2018/6/5/774</a><p><pre><code> Side note: I've merged it, and it's going through my build tests,
so it's really not that I hate the code.
But I really find that kind of one-sided rationale that ignores reality unacceptable.
And I find it dangerous, because it *sounds* so "obviously correct" to people who don't know any better.
If you don't know that gcc explicitly says that you should use unions to do type punning to avoid aliasing issues,
you might believe that union type punning is a bad thing from that commit message.
So it's dangerously misleading, because lots of people have a dangerous reverence for paper over reality.
In programming, "Appeal to Standards" should be considered a potential logical fallacy.
Standards have their place, but they definitely have their caveats too.</code></pre>
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.
Linus has long railed against the aspects of the C standard, and how they're been interpreted by compiler writers [0].<p>I'm not much of a C programmer, but the C aliasing rules are incredibly confusing, and seem to be interpreted differently by GCC and Clang. e.g. GCC allows type punning via unions[1], but Clang does not [2].<p>[0] <a href="https://www.cl.cam.ac.uk/~srk31/research/papers/kell17some-preprint.pdf" rel="nofollow">https://www.cl.cam.ac.uk/~srk31/research/papers/kell17some-p...</a><p>[1] <a href="https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Type-punning" rel="nofollow">https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Typ...</a><p>[2] <a href="https://bugs.llvm.org/show_bug.cgi?id=31928" rel="nofollow">https://bugs.llvm.org/show_bug.cgi?id=31928</a>
So much swearing to make three points:<p>1. What's in practice conflicts with what the standard prescribes<p>2. The reason it conflicts is because the standard is misguided and everyone knows that; for reliable code-generation you have to take the approach in the kernel<p>3. He disagrees with the rationale for the change, and wants a better reason for it
Strict aliasing shouldn't have been set as the default [1]. It was a huge mistake that instantly broke maybe all C programs everywhere. The standard also provided no guidance on how to work around the problem. `memcpy` is insufficient because it's a copy and that's a huge performance issue. Swapping through unions is UB. Casting about through `void * ` and `char * ` is gross, dangerous, and often runs afoul of alignment problems. It's a mess, and it has been for 20 years. Linus is right to be pissed.<p>[1]: <a href="https://blog.regehr.org/archives/1307" rel="nofollow">https://blog.regehr.org/archives/1307</a>
I read the comments here before I read the post and was honestly expecting a full out swear fest. Instead, I read linus being passionately expressive about something he clearly has strong opinions about... With a few swear words and over exaggerated metaphors thrown in.<p>I'm not saying that the language is not not-nice but it's not like he was being a bully or arsehole to someone in particular nor was he being over the top abusive. The delivery shouldn't be the take away here.
Reading it fully and it seems to line up with Torvalds attitudes towards things like userspace facing API stability.<p>Standards are standards, reality is reality, and when the two conflict the only way to maintain long term sanity is for the standard to be amended to fit reality.<p>The alternative is seen up and down userspace, where we have piles upon piles of workarounds, and whatsnot, to deal with APIs that change and break between releases because someone suddenly decided to re-read a standard spec like the devil reads the bible.
And he committed the patch anyway...<p><a href="https://lkml.org/lkml/2018/6/5/774" rel="nofollow">https://lkml.org/lkml/2018/6/5/774</a>
Every time I've gotten sucked into these <cough> notable LKML messages from Linus I'm not taken aback in the least.<p>To my ear, his language comes across as that of a drill sergeant: intentionally loud, pejorative, and foul for reasons of effectiveness, in addition to reinforcing the hierarchy he sits atop (as do the tirades of any prototypical drill sergeant).<p>My 0,02$.<p>NB: my parent cussed like a sailor, certainly influencing my PoV.
Is there any part of the standards process that is geared to the needs of the users of the compiler? Or is it all determined by the compiler writers themselves? I'm wondering why this kind of push back is necessary.
I can't imagine what it's like to be in Linus' position. After all these years he still hasn't found Linux's own Junio Hamano to turn over maintainer-ship to.
I wonder if there's a way to put all this engineering thought into reducing/simplifying standards and optimizing compilers so that individuals don't need a Linus-level knowledge.<p>In my opinion, the knowledge-cost of a system is a major downside that is often ignored (probably the biggest downside of unix, vi, git).
Honestly, I read a few sentences, began stumbling over the expletives, then decided I didn't care what the issue was or what his opinion is. Though he acts like everything that isn't done precisely as he would have done it in hindsight is "utter garbage", there are probably all kinds of historical
and logistical reasons that things were done a certain way and that doesn't make the people involved "f*cking morons." And, to save everyone the trouble, the usual refrain of "he's actually right" is meaningless to me.
I would rather that he made a standard wherein he specifies how he thinks the language should behave, and then followed that standard slavishly. One must follow _some_ standard slavishly!