Here's a mailing list message written by Linus Torvalds, original author and maintainer of the Linux kernel. It's unnecessarily mean. It also contains strong language, so probably don't put this on text-to-speech unless you want people around you to hear profanity.

The full email is reproduced below. We're also going to go through it piece by piece, so you can skip past this block quote if you don't mind seeing the email revealed piece by piece.

Honestly, this looks questionable to me.

I'm not talking about the changes themselves - I can live with them. But the _rationale_ is pure and utter garbage, and dangerously so.

The fact is, using a union to do type punning is the traditional AND STANDARD way to do type punning in gcc. In fact, it is the *documented* way to do it for gcc, when you are a f*cking moron and use "-fstrict-aliasing" and need to undo the braindamage that that piece of garbage C standard imposes.

So the commit message that talks about how horrible union aliasing is is pushing a story that is simply wrong. Using the standard to push it - the same standard that came up with the completely mis-guided aliasing rules - is not a valid argument.

Andy, what is the background for trying to push this idiocy? Don't tell me "the C standard is unclear". The C standard is _clearly_ bogus shit (see above on strict aliasing rules), and when it is bogus garbage, it needs to be explicitly ignored, and it needs per-compiler workarounds for braindamage. The exact same situation is true when there is some lack of clarity.

This is why we use -fwrapv, -fno-strict-aliasing etc. The standard simply is not *important*, when it is in direct conflict with reality and reliable code generation.

The *fact* is that gcc documents type punning through unions as the "right way". You may disagree with that, but putting some theoretical standards language over the *explicit* and long-time documentation of the main compiler we use is pure and utter bullshit.

I've said this before, and I'll say it again: a standards paper is just so much toilet paper when it conflicts with reality. It has absolutely _zero_ relevance. In fact, I'll take real toilet paper over standards any day, because at least that way I won't have splinters and ink up my arse.

So I want to see actual real arguments, not "the standard is unclear". When documented gcc behavior says one thing, and the standard might be unclear, we really don't care one whit about the lack of clarity in some standard.

So what's the _real_ reason for avoiding union aliasing?

There are competent people on standards bodies. But they aren't _always_ competent, and the translation of intent to English isn't always perfect either. So standards are not some kind of holy book that has to be revered. Standards too need to be questioned.

There's a lot of anger and frustration and profanity here: "bullshit", "f*cking moron", "piece of garbage", "splinters and ink up my arse", etc. When programmers read emails like this, there are three main types of response:

1. "This is bad. Nothing would be lost if Linus stopped doing this." If you're in this group, this post won't contain anything new for you.
2. "This seems bad, but I'm afraid that something will be lost if he stopped doing this." This blog post is written primarily for you.
3. "This isn't bad. People should learn to tolerate this or get off the Internet."

If you're in that third group, you might have noticed that your position is becoming less popular over time. Perhaps you aren't bothered at all by people calling your work "utter bullshit", calling you or others "f*cking morons", etc.

As you've noticed, other people are bothered by this stuff. If you insult people in professional interactions, you'll find yourself increasingly alienated and excluded simply because people don't like being insulted! (Though in an ideal world you'd avoid insulting people because it makes them feel bad!)

Let's rewrite this email to be less mean without removing any of the content. The full email will be reprinted here piece by piece. We won't do much editing for grammar or meaning; we won't remove any points that are made in the original; and we won't add any exposition. We're not trying to make it perfect.

First:

Honestly, this looks questionable to me.

I'm not talking about the changes themselves - I can live with them. But the _rationale_ is pure and utter garbage, and dangerously so.

The word "honestly" here doesn't mean "I am about to tell you the truth." It's the other meaning of "honestly": an expression of exasperation and disapproval, as in "honestly, did you think you were going to get away with that?" There's no reason to include that, or the "pure and utter garbage", or even the "I can live with them". All of those just mean "I dislike this."

The point of the email is that the rationale for the code change in question is wrong, and even dangerous. We can just say:

These changes look OK, but I'm not sure about the rationale.

Next:

The fact is, using a union to do type punning is the traditional AND STANDARD way to do type punning in gcc. In fact, it is the *documented* way to do it for gcc, when you are a f*cking moron and use "-fstrict-aliasing" and need to undo the braindamage that that piece of garbage C standard imposes.

So the commit message that talks about how horrible union aliasing is is pushing a story that is simply wrong. Using the standard to push it - the same standard that came up with the completely mis-guided aliasing rules - is not a valid argument.

We probably don't need to talk about "f*cking moron". The caps in "AND STANDARD" is another way to indicate frustration, like the "honestly" above. Likewise for "the fact is", the emphasis on "*documented*", "braindamage", "piece of garbage", and "pushing a story that is simply wrong". None of these carry any meaning about the technical problem; they're just expressions of anger. "Horrible" is a reference to what someone else said, so we'll leave it in.

Including all of this anger doesn't help the project or the reader. It takes up space and it makes the reader feel bad. We can argue that it "helps" people on Reddit who read the thread and think it's funny. But if you want to read people yelling about how bad code is, there are blogs for that; it doesn't need to be done on the mailing list for one of the most important software projects in the world.

Most critically, it's possible to describe the danger of Andy's rationale without the yelling:

Unions are the traditional and standard way to do type punning in gcc. They're also the documented way to do it for gcc when you use "-fstrict-aliasing" and need to undo the behavior imposed by the C standard.

I think that the commit message that talks about how horrible union aliasing is is wrong. Justifying this with the standard doesn't work because the standard specifies undesirable behavior to begin with.

I left the "is wrong" in. A lot of people would leave this out, but sometimes things really are wrong, and sometimes it's important. Given Linus' tone, he clearly thinks that it's important here, and I have tremendous faith in Linus as a C programmer.

I added "I think that..." because Linus acknowledges the possible existence of justifications that don't appeal to the C standards. He even asks Andy to provide those justifications, which we'll see soon. An unqualified "this is wrong" is inconsistent with that, so there's no need to use that harsher form.

Next, Linus yells at Andy directly:

Andy, what is the background for trying to push this idiocy? Don't tell me "the C standard is unclear". The C standard is _clearly_ bogus shit (see above on strict aliasing rules), and when it is bogus garbage, it needs to be explicitly ignored, and it needs per-compiler workarounds for braindamage. The exact same situation is true when there is some lack of clarity.

None of that serves any purpose; we already said that the standard specifies dangerous behavior that we don't want. We can drop all of this.

Next:

This is why we use -fwrapv, -fno-strict-aliasing etc. The standard simply is not *important*, when it is in direct conflict with reality and reliable code generation.

The *fact* is that gcc documents type punning through unions as the "right way". You may disagree with that, but putting some theoretical standards language over the *explicit* and long-time documentation of the main compiler we use is pure and utter bullshit.

I've said this before, and I'll say it again: a standards paper is just so much toilet paper when it conflicts with reality. It has absolutely _zero_ relevance. In fact, I'll take real toilet paper over standards any day, because at least that way I won't have splinters and ink up my arse.

The first paragraph here is a very strong argument, and it manages not to berate anyone! After that, Linus is back on his bullshit, both literally and figuratively. We can cut most of it, collapsing the second paragraph into one sentence and removing the third paragraph completely:

This is why we use -fwrapv, -fno-strict-aliasing etc.: if the standard conflicts with reliable code generation, the standard loses. GCC documents type punning through unions as the "right way", which I agree with. You may disagree, but if so you need to provide a justification beyond theoretical standards language.

That call to action at the end is important: if Andy disagrees, he should make his argument, but without appealing blindly to the standard. In the original, that call to action gets lost in all of the "bullshit"s and *emphasis* and _other emphasis_ and OTHER EMPHASIS and toilet paper.

Next:

So I want to see actual real arguments, not "the standard is unclear". When documented gcc behavior says one thing, and the standard might be unclear, we really don't care one whit about the lack of clarity in some standard.

This is just repetition; we already said that reliable code generation is more important than the standard. We can drop that paragraph.

Next:

So what's the _real_ reason for avoiding union aliasing?

There are competent people on standards bodies. But they aren't _always_ competent, and the translation of intent to English isn't always perfect either. So standards are not some kind of holy book that has to be revered. Standards too need to be questioned.

Suddenly Linus flips back from ranting to sensible advice. I like the "what's the real reason?" question, because it reiterates Linus' request for justification. If Andy doesn't want to follow GCC's recommendations on aliasing, he needs to provide an actual argument, not a simple appeal to authority. We'll leave the repetition in because this is both the core of the email and a genuine question that Linus is asking. I took a bit more editorial liberty here than in the sections above because this part is important:

There are competent people on standards bodies. But they make mistakes, and the translation of intent to English isn't always perfect. In this case, the standard conflicts with reality, so we ignore the standard. With that in mind, is there another, practical reason for avoiding union aliasing?

Now, here's the fully rewritten email:

These changes look OK, but I'm not sure about the rationale.

Unions are the traditional and standard way to do type punning in gcc. They're also the documented way to do it for gcc when you use "-fstrict-aliasing" and need to undo the behavior imposed by the C standard.

I think that the commit message that talks about how horrible union aliasing is is wrong. Justifying this with the standard doesn't work because the standard specifies undesirable behavior to begin with.

This is why we use -fwrapv, -fno-strict-aliasing etc.: if the standard conflicts with reliable code generation, the standard loses. GCC documents type punning through unions as the "right way", which I agree with. You may disagree, but if so you need to provide a justification beyond theoretical standards language.

There are competent people on standards bodies. But they make mistakes, and the translation of intent to English isn't always perfect. In this case, the standard conflicts with reality, so we ignore the standard. With that in mind, is there another, practical reason for avoiding union aliasing?

This is a much better email. It has 43% as many words, but loses none of the meaning. It's still forceful and unambiguous. With fewer words, it's easier for someone to absorb the core message about unthinking deference to standards.

It also doesn't berate anyone, building a needlessly antagonistic culture around the project. Writing this email instead of the original email doesn't require any extra work, and will save mileage on Linus' (or your) fingers besides.

If you were in the "I'm afraid that being nicer would hurt Linux" group, do you think that this email is worse? Is there any risk of a reader not understanding that the author disapproves of their reasoning and thinks that it's dangerous?