"Honestly, pure and utter garbage you are a f*cking moron and braindamage
piece of garbage horrible wrong. Completely mis-guided idiocy? Bogus
shit bogus garbage, braindamage.
Pure and utter bullshit. Toilet paper up my arse.
Linus"
Edit: Linus says it in public and it's just his gritty, bull-by-the-horns personality. Repeat it on an anonymous internet forum, though...
Linus has long railed against the aspects of the C standard, and how they're been interpreted by compiler writers [0].
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].
That was just a clang bug, and as I read the comments they fixed it quietly without exactly admitting as much. That kind of local bitsmithery on floating point values is a pervasive idiom, clearly explained by the syntax of the language, and the compiler had no business getting smart with it.
union and memcpy are known ways to do type-punning. Caveat to these is that they require at least one memory copy operation. Last I heard, clang and llvm's TBAA is still buggy.
It's a reasonable response, imho. The community wants to go in a given direction based on directed guidance, a standard. The community that follows the standard blindly lacks the intellectual tools to question the standard. The community needs the standard at the present moment but also needs directed guidance to be able to learn how to question the standard. It doesn't seem like hypocrisy to me, it just seems like he's annoyed at the general problem, aware that an individual mind does not have the capacity to solve the problem alone, aware that a collaborative effort is needed, and otherwise, venting, because problems like these are honestly, incredibly frustrating, especially when computers basically have to all be able to 'think' in ways that are more or less, equivalent, yet, humans don't think perfectly identically.
This is actually something I like about Linus, and one of the reasons I think the Linux kernel has been so successful: he merges stuff even when he doesn't personally agree with it or see the value in it. He has rejected plenty of stuff that would introduce problems, but despite the outwardly harsh attitude he works to try and make things acceptable so they can be merged.
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.
1. What's in practice conflicts with what the standard prescribes
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
3. He disagrees with the rationale for the change, and wants a better reason for it
I guess you're right that Linus was saying that -- after all, he considers the standard to be less important than toilet paper.
Regardless, if standards should be questioned, then surely Linus also should be questioned. I think a better rule would be: Appealing to the standard is sufficient reason for a change, unless a good argument can be made that the standard is BS.
Have we really? The post is over 100+ points right now. People seem to LIKE this swearing thing Linus does.
I don't think its healthy for the general programming community. The tone that was written here is certainly not acceptable behavior on YCombinator in general. But we put up with Linus because... well... Linus is an elevated programmer and we all respect him. For better or for worse.
Some of us find it reassuring someone cares enough to go on hyperbolic comedic rants from time to time. I know I enjoy seeing the moon pretty much every day, it's reassuring, even if it's made of cheese.
I think people misunderstood my comment. I'm very pro-Linus swearing, inasmuch as he just is who he is and people shaming him for swearing are yelling at clouds.
By my count there is one f*cking, one bullshit, one shit and one arse, hardly "so much swearing". I think anyone complaining about that is way to sensitive.
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).
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.
It is ironic that his own arguments about the standards can be applied to his own attempts to convey ideas, persuade other people, and collaborate effectively with other human beings.
It's not really ironic, computers and programs are different from ideas and minds. His complaint is about computation and maintaining uniformity in computational philosophy, which is meant to allow development to flow with the least performance issues possible.
Ideas can be impassioned, wrong, clever, ridiculous, circular, etc. Computation shouldn't be, but often is, because, preference.
It's hard to hold all that stuff in one's head alone, and consistently feel like every time a problem is solved, a new one magically gets created, without having anyone to talk to, that really 'gets it', without that person pushing every single button you have about preference in computation.
You missed the point. He is haranguing about ignoring reality, all the while ignoring the reality of how to effectively work in groups. His method of interacting with people is an idiotic way of doing that and he damn well knows that and just doesn't give a fuck and yet he wants to hold others to that standard in other areas.
He's talking about computation, getting the computations to be correct. If you read the end of his message he's well aware that the reality of thinking in groups and transmitting ideas through non-computational language are flawed.
It's an idiot way to you because you are too sensitive to it.
I could very well point out how idiotic it is to say a person is an idiot for calling other people idiots, but honestly I'd rather just laugh at the insanity computation tends to bring out in all those that have to work on computers with other people.
> He's talking about computation, getting the computations to be correct.
Irrelevant to my point.
> If you read the end of his message he's well aware that the reality of minds and ideas are flawed.
And he still doesn't work with in the confines of human social behavior.
> It's an idiot way to you because you are too sensitive to it.
And when it hinders his ability to get things done because other people think he's an asshole, I'm sure you'll still be here saying "hurrrrr durrrrr stop being so sensitive".
> I could very well point out how idiotic it is to say a person is an idiot for calling other people idiots,
If you want to think calling someone an idiot for idiotic behavior is idiotic, then you're pretty sensitive. However since I don't need you to do anything for me, it doesn't hurt me in any way to treat you like an ass.
Your point is weakened by the fact that Linus has managed an enormous project for decades with incredible success. That scores some reality and effectiveness points, surely.
I have not. I choose not to grumble in public that the enormous contribution to the world of a master craftsman could have been even more enormous if he'd done things the way I prefer instead of whatever way works for him.
And then I get back to work using his software which I paid close to zero dollars for.
Is there another gift horse whose mouth is so frequently inspected as Linus?
Oh excuse me, I should bend over for him then! Because his achievements are so great, he must be immune to criticism!!!
> the enormous contribution to the world of a master craftsman could have been even more enormous
Hardly, it's about the contributions that don't exist from other people because of the insufferable shit-headedness of working with him. But that doesn't matter to you because we can't criticize him now can we? No, we must bend over because he is so much better than us!
Is conversation not a limited form of collaboration?
I've got to say, I find it really hard to take your outrage at a little mild profanity seriously if you so casually use it yourself during normal conversations. To be frank, I think you're just pretending to be offended Linus using profanity.
Your inability to realize that the the context of my criticism is on his ability to collaborate and that that doesn't apply to how I express myself in public is laudable.
I don't think a "civil tone" is necessary; directed anger can be good and helpful. The problem with Linus is that he just smears it around aimlessly, adding lots of boring noise to what may have been an interesting technical argument.
It's not real anger, is my point. It's just shit-stirring. Unless he's got far less self-awareness than I credit a functioning adult of his industry stature, he has to know that people reading his "idiot fucking brain-damage" spiel sort of roll their eyes and think "there goes Linus again"; nobody stops, catches a breath, and thinks "damn, he's really upset this time".
> roll their eyes and think "there goes Linus again"
You both seem to be unaware, that emotional responses are not universal. A swear word in a second language and a different less sensitive culture doesn't feel like much to cause anyone to care enough to roll their eyes.
When I hear open source maintainers talk about their woes, it tends to be that they are a single person and their are many people who try to contribute who think they are offering great things, but who are in fact just giving them shit that they must then maintain for the rest of their lives.
In a world in which there are only two people communicating with each other, you're definitely right that the point he is making can be made better. But consider that he just made his point to thousands upon thousands of potential contributors, because the message was shared. This directly addresses two of the things I hear open source maintainers complain about: it discourages the giving of shitty things and it moves away from the poorly scaling one on one communication.
I also feel like we see every single abrasive Linus email hauled out of context to make this point that he's an over-dramatic asshat, and not the mountain of mundane ones where he isn't torching somebody to make a point.
> The problem with Linus is that he just smears it around aimlessly
I take it you don't really read a lot of Linus' mail? I find it hard to believe that somebody would think that, unless they only got to see a highly biased selection of his emails.
Also, consider that we would never have had this thread in which several people are learning about gcc's documented behavior on unions if it hadn't been for the somewhat strong language. It serves a genuine purpose.
What's funny is that, because you're an anonymous nobody, Linus's style would probably be more effective for you. Nobody knows already to assume there's an endless torrent of pointless barking that accompanies all of your commentary. People might actually think you mean it.
I mean, you'd get your comments flagged off HN, but other than that: it could work for you.
Unfortunately, for Torvalds, we're all in on the joke.
The problem is, well, it's just like my bulldog Reinforcements. He doesn't like hats. He sees someone walking down the street wearing a hat, he barks loudly. He barks a lot because of this. When I'm across the house and I hear him bark, I have to try to determine whether something important is happening, or just a hat. It's an impediment to our communication, me and my dog. Same with Torvalds. He sees a lot of hats, is what I'm saying.
It could be worse. My dogs bark at anything and everything with a pulse that walks by. That's the equivalent of someone waiting on all mailing list correspondence/repo traffic for anything and everything to blow up at, and people like that do exist. Fortunately, they rarely make an impact to be important enough to listen to.
Or you just stop hearing the barking, like the annoying dog in my neighbor's yard. I've mostly stopped noticing that the damn thing barks 8 hours a day. But if it yelps instead of barking, I notice immediately.
Most of us will perk up a lot if Torvalds has something nice to say, even among the barking. Communication is complex.
This analogy with your bulldog and the world's hats, it was the very first time in 20 years that made Linus' [negative] swearing problem click in my mind.
What's soft-pedaled dreck there? It's very straightforward, e.g.: "He deploys it so casually you just assume it isn't serious."
You could argue that "continuing to try to affect his Andrew Dice Clay of Programming persona" isn't super clear, but it also doesn't fit "soft-pedaled politically-correct," really.
I consider his post fully appropriate, as I share his view of the quality of that aspect of the standard. The standard, for this specific issue, is so obviously unbelievably wrong, so much that it deserves the worst words to describe it, just to give the clearer view of wrongness to the readers.
At this point, if that's true, he should have written his condemnation very carefully and subtly. People would flip their shit; Linus must really be mad now!
What I read in your comments here is just "I know Linus uses strong language, and therefore I can't figure out if he's right or not."
Which is wrong approach to your figuring out that. Instead, you can have only two approaches:
- learn enough about the topic discussed to have your own opinion
or
- consider how often Linus was wrong in his "expert" opinions (From my point of view, he's almost always right, but you are free to give the example of the opposite if you have them) and use that as a starting point.
Note: both approaches are completely independent of the speech figures of Linus' post, which is how it should be.
I personally, for myself, came to conclusion that most of the time, specifically for the issues I know more than enough to have my own opinion, I can trust that Linus' opinion will match my. And if it doesn't happen, that he will probably still be right and I have to reevaluate my initial opinion.
In this specific case, I would be very glad that people here try to even give some reasonable arguments why he would be wrong. Because "it's in standard" is not a valid argument, as soon as you accept that the standards definitely aren't guaranteed to be without even big errors.
The most problematic attitude I see is exactly like 'ramshorns (parallel post) asking "How can the standard be wrong" (the right question would be "where is the standard wrong"). The answer to the former:
A standard is just a document produced by a group of people trying to specify something. There's nothing that guarantees in any way that the product of any group of people doesn't contain errors.
The answer to the later: In this case, the standard "resolution" of the real need is obviously wrong, because the "resolution" is pretending that the need doesn't exist. And the need not only exists but is fundamentally necessary for the use cases where C is being used: being "low level" enough not to incur unnecessary penalties to implement something that is "natural" on the hardware level. Unions were used for decades to fulfill exactly that specific need that the standard body somehow managed to "ignore" and the compiler implementers looking for a "loophole" to produce unusable code sadly want to use. Such attitudes, both by standard bodies and by such implementers are also wrong.
edit: re tedunangst's "Linus is yelling. Do I care? Should I care? Is there any meaningful signal from the yelling" please read this my post again. I assumed I'm answering exactly this. And my opinion is really: you can assume Linus is right. He was so often right for such technical issues that it's a good start. Then, yes, care. Yes, you should, if the technical topics discussed have connection with what your work is. And if you don't program in C, and don't influence those who do, you can of course ignore the whole thing, but then the question is why are you involved now in the topic's discussion or consideration.
And for those that believe that there is really no correlation between Linus using strong language and him being rightly against some "practice," they should provide some proof that such correlation is negative or doesn't exist, as much as I know, it exists and is actually positive, exactly for some big issues I care about.
Linus is yelling. Do I care? Should I care? Is there any meaningful signal from the yelling to suggest that this is more important than, say, people who misspell commit messages?
The standard massively conflicts with the practices used in existing C programs by existing C programmers. Yes, it's perfectly possible to write code that doesn't violate any of the (largely implicit, it's worth noting) strict-aliasing rules. But was it a good idea for the standard to allow optimizing compilers to silently break massive amounts of existing code that has worked for years? Even if that were acceptable, was it a good idea for the standard to disallow one of the more ergonomic and explicit ways (using a union) of reinterpreting an object as an object of a different type?
Good point that his style and profanity is intentional. But perhaps he uses the non-civil tone to drive home the point which he makes it clearer in the follow up mail [1]. Especially because the original commit message [2] he is complaining about goes overboard in appealing to the C standards and I think Linus is concerned that other people might think that is the recommended approach when the opposite is true as far as the Linux kernel code is concerned.
What makes you think Linus would be more effective if he used a different tone? That seems like a tough argument to win given how tremendously effective he is. It doesn't seem like an exaggeration to me to say that Linux is the most successful opensource project of all time and among the best managed of all time in terms of the number of use cases it's managed to address over time and the number of people who have contributed. Not, I will grant, in terms of number of people whose feelings have been hurt. But I fail to see the evidence that Linux would actually be better off if Linus behaved differently. If we had good Linus and bad Linus we could A/B test, but sadly, we don't. We just have the one Linus, and he's been more effective than anyone in opensource over the last 20+ years. So it seems a lot more likely to me that his behavior is part of that effectiveness, not in opposition to it.
This assumes consistency of tone over time. It'd be interesting to get some data on how his approach has varied over those 20 years. It'd also be difficult, since this is a somewhat subjective measurement, but perhaps a PPP (profanity per paragraph) metric.
Linus used to be much more polite... until some developer attempted suicide after discovering, too late, that their patches were not going to be merged.
Since then he's much more direct, and his SPP (suicide per paragraph) metric is much better.
You have it reversed. The only thing that makes his behaviour slightly bearable to others is his effectiveness. Otherwise the community would've dumped him right away. Not like there's any reason not to, except for his technical knowledge.
Cripes. He's not the first opinionated, yet strangely effective Engineer the world has ever seen and will not be the last either.
I personally happen to like his approach in general but as I'm sure you are aware: "You can please some of the people most of the time and most of the people some of the time but this aphorism sounds a bit tired these days"
I don't really think this is about pleasing people or not. More about self respect. I for one would have to be way too drunk to pun on a shitshow like this in public, also when there's no apparent reason.
But well that problem belongs to those who work with him, so I don't care. All I wanted to say is that because he gets away with it, it does not mean that us the halflings will too, so that's not a good advice to somebody thinking of participating in the general open source sphere.
Dunno, whenever I dig into one of the "shitshows" I find I mostly agree with it. I'd say a decent fraction of the ones that make hacker news are some form of "Don't break userspace". He obviously feels it's quite important, and there's been several cases of failed perception (like the gnome folks breaking userspace "like linux does").
Sometimes it's worth being a bit over the top so that the entire community you are working with gets the message loud and clear. Seems like other communities (like bsd, gnome, debian, etc), often have extensive documentation, policies, and best practices... which are often ignored because every developer doesn't keep 100% of the best practices in mind at all times.
I suspect a big part of why user space is broken so rarely in Linux is exactly because Linus has made such a big deal about it in the past.
I suspect a big part of why user space is broken so rarely in Linux is exactly because Linus has made such a big deal about it in the past.
Its almost as though he identified a weak point and ameliorated it! That's what an Engineer does.
which are often ignored because every developer doesn't keep 100% of the best practices in mind at all times.
There is no such thing as best practice - that is a nonsensical phrase that I think someone involved with MS created many moons ago and caught on in IT and I absolutely despise. There is good and bad practice but you had better be very, very good at something to tell me that you know best about that something.
I was referring to the delivery more than the content. Frankly I don't know much about his side of computing, so I cannot agree or disagree anyways. My message in this thread is to the random guy getting into FOSS: don't make an annoying freaky nerd out of yourself becaue one particular annoying freaky nerd has been very successful. That he is so is not necessarily the cause of his success, and might even be invisibly detrimental to it.
> That he is so is not necessarily the cause of his success, and might even be invisibly detrimental to it.
I do not know him personally, but people who do know him comment that he is a nice, considerate, thoughtful person.
Linus has actually chimed into this metadiscussion in the past, basically saying something along the lines of "the audience is too big and too varied to be subtle. If I am not very explicit, someone will misunderstand this, usually as an invitation to keep wasting my time" (IIRC) -- which, having managed much much smaller projects, I tend to agree with and can only imagine how much more true this is an the Linux Kernel scale.
The Finns I know are all very direct "straight shooters" - I guess that's part of it.
> That he is so is not necessarily the cause of his success, and might even be invisibly detrimental to it.
From three decades in the industry, I would say it's likely contributing to his success (though, it is independent of the cause/origin of his success, which is being smart, diligent, persistent and lucky). The ability to cut down and through bullshit is IMO fundamental, and it seems impossible to do without occasionally being rude.
You can still be direct without having to act out or treat people like they're idiots.
It is not impossible to narrow down the complaints without being rude. Most people do that just fine, with way larger projects than his kernel.
His behaviour is just unnecessary and distracting. It's almost as if he does it for publicity or shock value. Maybe that contributes to his success, but it shouldn't.
I find it weird that people try to defend him rather than acknowledge it is just one of his character flaws. People aren't perfect, and neither is he. Doesn't take from his achievements but acting like he's in the right to behave this way is just enabling him. If people want to emulate him, they should look at the good and leave the asshole behaviour behind.
> Most people do that just fine, with way larger projects than his kernel.
What are your examples? Please qualify project size by number of contributors and their organizational and cultural diversity.
According to [0], in 2015-2016 there were over 5,000 contributors sending patches, representing over 500 organizations (and likely, something like 50 countries/cultures/languages). Linus, through the LKML, corresponds with many of them, and has a small number of deputies. He is not paying any of these contributors, so he can't actually fire them, unlike e.g. Zuck, Jobs or Gates which, according to rumour, are/were all much less polite than Linus to their subordinates.
> It's almost as if he does it for publicity or shock value
He most definitely does, and uses it effectively. When he does, he mostly attacks ideas, not people. I've been following the LKML very intermittently, but my impression is that he is mostly kind and thoughtful in his answers while being direct. Those times that get to HN/Slashdot/Reddit/common-knowledge are few and far between, and mostly the 3rd or so response to the same thing (though, it has happened before on a "first offence").
> People aren't perfect, and neither is he. Doesn't take from his achievements but acting like he's in the right to behave this way is just enabling him. If people want to emulate him, they should look at the good and leave the asshole behaviour behind.
No one said he was perfect. Some of us believe that it is effective; call it "necesary evil", but it's one of the very few management tools that he has - basically, refusing a merge, and voicing an opinion.
I eagerly await your examples, as my experience is that people with much more management tools at their disposal are not better in this respect than Linus. Especially those examples (of "most people") that coordinate submission from 5,000 people mostly interacting directly with them.
> Especially those examples (of "most people") that coordinate submission from 5,000 people mostly interacting directly with them.
This is wrong. He has said himself on video multiple times that his correspondents are the subsytem maintainers, which are way fewer in number (a handful of people).
He is on the LKML[0], and does respond to many people, not just the handful of maintainers. I'm sure he doesn't read the entirety of the LKML (hundreds of messages per day), and for sure he has a private channel (mailing list or otherwise) with subsystem maintainers, but he DOES correspond with a lot more than that handful, and when I was reading the LKML, he would even occasionally respond to first-time posters.
Well, look up what companies like IBM, Google, Amazon, etc. are doing with thousands of workers and all the organizational and cultural diversity you want.
I don't get what is "necessary" with his insults. Would delivering the message calmly not be understood?
There's nothing to make anyone believe it's an "effective" strategy. Some people are deterred from contributing because this guy can't act professionally. The only reason people still want to contribute is because of the importance of the project (aka thousands of projects depend on a good linux kernel).
He can accomplish the same things, without going ballistic, in shorter time and with the respect of others earned. It's still using the same few management tools and he can retain his bad temper for when a situation actually calls for it (which is almost never). Blowing everything out of proportion is crying wolf.
Maybe he is not that bad of a person to work with. Hopefully lower than how bad Gates and Jobs were. But he sure seems to hide it well since that's all I ever hear about him. But I guess bad publicity is still publicity.
> Well, look up what companies like IBM, Google, Amazon,
Does any of these companies run a team with 5,000 people contributing to the same codebase?
Do you have it on good authority that most of the people in IBM, Google, and Amazon that manage those 5,000 people teams are nice and polite? Because I've heard a lot about Amazon to the contrary. Do consider your selection bias: You know everything Linus tells the world, you only hear about Ballmer's chair throwing, but not any other profanities,
> Would delivering the message calmly not be understood?
Yes, he tries/tried occasionally. The wikipedia entry for LKML has more info.
> He can accomplish the same things, without going ballistic, in shorter time and with the respect of others earned
That goes counter to Linus' experience, and a few other people's.
> It's still using the same few management tools and he can retain his bad temper for when a situation actually calls for it (which is almost never). Blowing everything out of proportion is crying wolf.
Are you on the LKML? He almost never does it. You hear about it when he does. He is not shy with criticism, and he never sugarcoats anything, sure, but he goes ballistic very rarely.
> But he sure seems to hide it well since that's all I ever hear about him. But I guess bad publicity is still publicity.
You admit that you have no idea what happens between the times you hear of him. You implicitly say your model is "IBM, Amazon and Google", in which you hear nothing of how disagreements are handled, and none of which have the scale and diversity of the LKML in a single team.
It is my impression that your beliefs are not grounded in data or even anecdata. It does not make them wrong, and I'm not saying you are wrong. I'm saying you have not made any convincing argument to say you are right.
It is very rare to see him treat people like they're idiots.
There's a very fine but very clear line in a lot of his rants between very harsh language used against solutions he doesn't like, but without making it personal, like in this case where he's attacking the rationale, and attacking the C standard, but is very explicitly avoiding attacking the people (even taking pains to point out he's not suggesting people on standard bodies in general are incompetent). The closest he comes to attacking people directly here is when he calls people who use -fstrict-aliasing "fcking morons" when* they use -fstrict-aliasing, so even that is conditional on behaviour rather than assigning a trait to the person in general. You'll sometimes see him making wide-ranging accusations about general categories of people (e.g. I remember a rant about people who think it's a good idea to do reads a byte at a time), but rarely about specific people.
On the rare occasions when he attacks people directly, I have yet to seen an example which doesn't fall in the category of either attacking persistent repeat offenders who has refused to listen to more polite rebukes (his attack on Kai Sivers being the most obvious example [1] - notably while very direct and personal, that rant was also comparatively civil in terms of actual language), or attacks that fall in the "I know you know so much better, or you wouldn't be in the trusted position you're in" category (his attack on Mauro Carvalho Chehab for a change that broke userspace [2] falls in that category; Mauro has contributed to the kernel since 2005, and have worked on it as his job for years - in this case Mauro took it on his chin, apologised for the breakage and the discussion remained strictly on topic on the technical issues afterwards).
Frankly if I'd gotten a dressing down by Linus in that category, I'd print it out and frame it, because harsh as they may be, I don't know of any case of people having gotten those without having demonstrated time and time again that they should know better first. You don't see him ranting like that at beginners. You see him ranting like that when he's disappointed because he has high expectations of you. Doesn't mean people can't get upset by them, of course, but it changes the nature of it quite a bit.
Note that I'm not saying that it's a good thing- I'm sure there'd be more civil ways to express that too -, just that I think the importance of these rants is exaggerated.
I don't understand why people feel the need to go Kremlinologist on his tone.
He swears a lot. Who the fuck cares? His audience isn't HN or The Register or anyone else not doing kernel development.
The apparent desire for bland, well-scrubbed and boring is not universal. I haven't heard of a sudden increase in demand for talk therapy for kernel devs. Lots of engineers swear a lot, and that's unlikely to change anytime soon.
Now, if you'd like to discuss actual abusive managerial behavior, we could have something to talk about.
I haven't spent much (any) time listening to him, just heard that he behaves badly sometimes. This swearing of him, is it because he is finnish? They are known to be quite dirty in the mouth-department when they are upset.
When you debug a distributed system or an OS kernel, you do it Texas-style. You gather some mean, stoic people, people who have seen things die, and you get some primitive tools, like a compass and a rucksack and a stick that’s pointed on one end, and you walk into the wilderness and you look for trouble, possibly while using chewing tobacco.
"""
Kernel developers tend to, in my experience, be a specific type of person. They are writing software that will possibly save someone's life today. Billions of dollars changing hands using their code every second.
The average programmer on HN does not write code that will see more than a couple thousand users at once. Even people at google usually don't write code as important as the linux kernel (they write on top of the kernel, usually).
---
There is also some narrativ that Linus is being abusive and I kinda disagree. Linus doesn't take a dump on people who don't know better, he takes a dump on people who should definitely know better and who are long time kernel contributors in important positions. Because these people count. (Plus, he's finnish)
No, he's wrong. Aliasing between union members has never been defined behavior. It just happened to work.
Now that optimizers are getting better, these long-standing issues are starting to surface in the real world. This is no different from when programmers do something dumb like
j = i++ * i++;
which works until it doesn't. Or worse, someone runs Stroutroup's book through a static code analyzer and finds a wall of errors so the language is changed [1].
Code around it and move on -- as in the patch mentioned.
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).
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.
> 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.
Negative experiences create far stronger memories. That's just how the brain works. You can walk great distances and barely remember the places you passed through, but if you step on a nail at some point you'll never forget that event. That memory is simply much stronger than the others.
How many email messages does Linus send in a year? How many of those messages contain rants so epic they get posted here? I bet it's less 1% of all messages. Yet everyone remembers those messages and what they say. He might not be polite, but he gets his point across.
Maybe it's a cultural thing? I don't find the language as being particularly abrasive, only as having personality, and quite expressive. But then swearing and cursing seems to be much more accepted in most of Scandinavia than it is in much of the English speaking world.
If the Swedish speaking minority of Finland is speaking anything like the good people of Åland, well, then it could be interpreted as trying to be quite polite. Never met any people who could get more obscenities into the most casual and every-day conversations then they can. It's really quite impressive.
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.
Lets break it down.
In C, type-punning is NOT part of the language. Its technically "undefined behavior". There's an expectation that when you do:
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??)
When an optimizer can assume, and when it can't assume, "aliasing" is very much an undefined behavior within the C language.
-------------
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.
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.
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.
Pointers are converted in order that they be used. Though the uses may be undefined, there is value in the conversion having a well-defined syntax. In effect, C and C++ allow certain intents to be expressed in a common way, without requiring implementations to make those intents work. This is better than having compiler-specific syntax for that sort of thing.
Nonsense. Aliasing unlike-typed objects via memcpy is equivalent to pointer aliasing. memcpy has void pointer arguments. You're relying on the addresses of the source and destination objects being converted to void pointer.
All type punning is in the hands of the implementation. The language definition provides the syntax for it, which has the virtuel that all code which attempts to do type punning expresses it in the same manner. However, the language leaves it up to implementations to define whether type punning works, and with what caveats and restrictions.
> E.g. you can't memcpy a uint64 to a double and expect well-defined behavior.
Yes, you can. The behavior is implementation-defined but not undefined. (Well, it can trigger undefined behavior if the value corresponds to a signaling NaN, or if the implementation uses a nonstandard, non-IEEE format for doubles that has other "trap representations". But it's not otherwise undefined.)
The basis for this is that the aliasing rule has an explicit exception for reading or writing to objects using char pointers, i.e. byte-by-byte, regardless of the object's type. This exception is in both the C standard:
The memcpy function is defined as copying characters, so the exception applies to it too.
Both standards also explicitly define that objects (at least of POD types) have byte representations and those representations are implementation-defined (as opposed to triggering undefined behavior if you depend on them). For C:
> Except for bit-fields, objects are composed of contiguous sequences of one or more bytes, the number, order, and encoding of which are either explicitly specified or implementation-defined.
"access" refers to reading there. Not reading or writing. Objects may be treated as arrays of character type to the extent that their value may be examined that way.
If you memcpy a uint64_t to a double, the implementation is not required to notice that the double variable's value has changed; a subsequent access to that variable can continue to refer to a register. It's not a matter of what bit pattern was stored there.
> 3.1
> 1 access
>〈execution-time action〉 to read or modify the value of an object
Thus, the requirement is symmetrical. The compiler must consider any char write as potentially aliasing a subsequent read (or write) of any type, unless it can prove non-aliasing without depending on type. And similarly, it must consider a write of any type as potentially aliasing a subsequent char read/write.
> the general expectation that everyone knows the intricacies of GCC to properly understand the kernel code is misplaced IMO
But this isn't just a person trying to properly understand the kernel code. It's someone who's trying to merge a change that's motivated by following a standard. If you're making a change to code based on a standard then yeah, you should know the intricacies of how the compiler implements that standard. Because, as Linus keeps coming back to, that's reality, that's what's actually going to impact users and other devs: the intricacies.
This change strictly makes the Linux kernel more in line with the C Standard, so it may compile better in CLang.
There's literally nothing wrong here. The code is more correct and more conformant with the C-Standard. So why is Linus against it?
Hint: he really isn't. Linus accepted the code anyway.
I dunno, the more and more I look into this, the more I feel like its just another example of Linus unnecessarily flaming someone on the developer communication channels.
Well Linus says that he's not against the code but the reasoning in the original post and I think his whole point is that neither of those arguments are good reasons to make a change. He doesn't specifically mention CLang, so I'm not sure how much he values compiling on that, but he clearly doesn't value conformation to the C Standard. Saying "This change strictly makes the Linux kernel more in line with the C Standard" and concluding there's literally nothing wrong here and that it's strictly more correct this way seems to be the opposite of Linus' opinion, and mine. It's fine to disagree with that, but don't act as if this is just unnecessary flaming by Linus without a purpose.
By removing the non-standard GCC-specific union{} methodology from the code, the contributor necessarily improved portability to CLang. That's just the facts.
Clang now follows GCC's behavior with regard to that specific example, which makes sense, as Clang more or less explicitly aims to correctly compile the GNU dialect of C.
I think it's reasonable (and even important) for Linus to emphasize that the kernel is coded in GNU C, not strictly standards-compliant C.
> Clang more or less explicitly aims to correctly compile the GNU dialect of C
That was super important as the compiler was first starting out, because (A) Apple's existing code was built with GCC, so it relied on GCC flags & extensions, and (B) for it to be a viable open source compiler, it needed to build large existing codebases which were already using GCC.
However, that doesn't mean that Clang will always continue to support every thing GCC does. Whether they by design or by accident, incompatibilities will arise. Of course, projects as tightly coupled to GCC as the Linux kernel might not care.
Stop spreading complete bullshit and go read https://en.cppreference.com/w/cpp/language/reinterpret_cast already. C++ has strict aliasing rules (probably even stricter than C) and reinterpret_cast can do absolutely nothing to workaround them. It is of no help because it certainly not allow you to access objects with a wrong type. It merely reinterpret the type of values, or values as far as the implementation is concerned (C++ reference, which are only pointers with syntactic sugar plus a few extra restrictions). In the C++ community, the current thinking is that memcpy allows to type pun, but IIRC the C++ standard is actually not even clear as for why this is the case, and in its current writing it might be that there is actually no way. Short of memcpy you need at least a placement new on a trivial type. And sometimes even other cases of insanity, like std::launder. Hell, sometimes you even need std::launder for the same type.
Short of converting void* (or sufficiently large ints) to T* because of legacy API, I'm not sure reinterpret_cast has any portable use. But I'm sure you can NOT type pun with it if that would break the aliasing rules.
Very cool; you just use these macros for all your casts, and when building using a C++ compiler, you get additional diagnostics, like that you're accidentally stripping away a const-qualifier.
is valid C++ and equivalent to using reinterpret_cast. Here, this is the same thing (in C++) as
*reinterpret_cast<int *>(foo) = 0x12345678
It is not well-defined behavior.
C++ has just divided the behavior of the (TYPE) cast notation in terms of more specific kinds of casts which are mutually exclusive. If a qualifier is being removed, you must use const_cast, which will not change type. The C-style-cast notation automatically chooses the right combination of C++-style casts to do the job. So for instance a C style cast from "const char " to "void ":
So the "bad" thing about the C-style cast notation then is that no matter how you change how the inputs are declared elsewhere, it will just "do what you ask", in the spirit of the C language. Whereas the C++ style casts will diagnose if the input types change so that they are not applicable.
E.g. reinterpret_cast is not so powerful that it will strip away qualifiers:
> 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.
If you need type-punning, use a union. Done and done.
You're just making an appeal to authority here and deciding that The C++ Standards Committee (who give us one official way to do this) is a better authority than The GCC Authors (who give us another).
And that's shortsighted and silly, because GCC (being working software) is if anything a more reliable and more accessible authority than any spec-writer will ever be. That's exactly the point Linus was making, albeit with more profanity.
> And that's shortsighted and silly, because GCC (being working software) is if anything a more reliable and more accessible authority than any spec-writer will ever be.
Well, until you decide to use CLang, ICC, or Visual Studio or something out there. The reason why people follow the standards is because they want their code to correctly work on more than just one compiler.
No, that's exactly backwards. In fact ICC and Clang (I have no idea about VS) both follow GCC on this particular feature, largely because important software like Linux relies on GCC's useful and practical feature set. See also support for GCC's struct initializer syntax, statement expressions, inline assembly constraint system, etc... GCC invented all this stuff, and software developers everywhere (Hi!) love them and use them, and the industry follows suit.
Fundamentally you're still missing the point. Standards are important. Features are more important. The best standards are ones driven by features and not paper. GCC has been a far better, more innovative, and more practical driver of "standards" than any committee.
You can't cast a short ptr to an int ptr safely even ignoring aliasing rules. What bites you is that ints have different alignment than shorts (2 vs 4), so while this works on e.g. x86 almost always [1], your code won't always work on machines that can't do unaligned int reads.
There are a lot of sharp edges to C/++ and the community really is hurting for a good static analyzer that can at least save you from most of them.
[1] almost always, because while a simple unaligned mov is safe, if the compiler unrolls and vectorises your loop, it is free to then use aligned sse read instructions, assuming that your int ptr is aligned, because pointers must be aligned according to their type. Then your program crashes, but only in optimised builds.
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.
> And I find it dangerous, because it sounds so "obviously correct" to people who don't know any better.
> So it's dangerously misleading, because lots of people have a dangerous reverence for paper over reality.
It's the same thing everywhere. You see it as "famous person said X" or "the standard is X" or "the industry does X" or "X is popular". Then you talk shit about X, because you actually know it's not right, and people dump on you because you're a heretic, or not famous, or not an authority, or don't have "a piece of paper" to quote from.
Everybody just goes with what sounds right rather than what is proven right.
>Everybody just goes with what sounds right rather than what is proven right.
I'll just throw out the corner case that sometimes that's just what you... do to get through the day. I might not give others advice on it because I don't know, but often I don't know enough and someone better says "naw that will give you trouble down the line" and stuff has to get done so I do the thing the way I was told.
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.
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.
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.
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.
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.
Generally speaking, if a memcpy's size argument is a constant expression equal to the size of a native integer type, it will be transformed to a native load from the source pointer followed by a store to the destination pointer. After that, the load or store operation (or both) may itself be optimized away if the pointer points to a local variable. Thus, for example, given something like:
void write32(int *ptr, int val) {
memcpy(ptr, &val, 4);
}
…the load is removed entirely, and the store is kept but becomes a native store:
Reading from a union field other than the one last written to is explicitly UB. I wish this worked too, but it doesn't (compiler-specific guarantees aside).
It's actually well-defined in the C standard (although the format of the byte representation is implementation-defined), but undefined behavior in the C++ standard:
Since Linux is C, not C++, it should be fine; the author of the patch is just mistaken.
(Note that in practice, this will work in C++ too, since most compilers support both C and C++ and don't change their optimization behavior based on which mode the code was compiled in; but of course there's no guarantee this won't change in the future.)
Not all compilers handle it like you'd expect, and it looks like that's because it's actually unspecified in the standard [1].
But furthermore, this will really only work for scalars. Plus you have to go and declare a whole new type to cast things safely. It's extremely awkward.
> Casting about through `void ` and `char * ` is gross, dangerous, and often runs afoul of alignment problems.*
This just highlights why strict aliasing rules exists. Because the exact same alignment problems is what you get when you type pun. Looking at the raw data as a char* or memcpy'ing it just makes it more visible that what you are doing is wrong.
The only valid reason to do type punning is to serialize data and then deserialize it back to exactly the same type. And since type puning with char* is defined as ok so there is no problem. I am having a really hard time seeing other valid reasons to do type punning and have never ever had to use it myself.
Seriously, why are people upset over strict aliasing? What is the valid use case for type punning that people are missing?
Mostly you run into problems either using the "inheritance" pattern, or with discriminated unions. These are pretty common in C. There really is no alternative to inheritance because if you don't type pun you end up needing to copy a lot (or you can pass around pointers to internal members but it's really easy to lose track of memory that way). And there's also not really an alternative for discriminated unions; the functionality is pretty unique. You can pull the polymorphism out of the type up to the top of your control flow, but that severely degrades your locality. In other words, at some point you have different batches of functions for each "type", but you don't realize that's what they are until you trace the call graph all the way up. Of course, sometimes that's preferable to avoid branching, but at least w/ discriminated unions you get the option.
1. Discriminated unions don't have any issues with strict aliasing, you are allowed to read a union member as long as it was the last union member being written to, and the tag-member helps you identify that.
2. If you are trying to retrofit polymorphism in C maybe you are using the wrong tool for the job.
3. If you really want polymorphism you can create baseclass-struct with a void* this pointer and a bunch of function pointers as instance-functions. To "override" the struct you just instantiate it with different function pointers. If you want to inherit an existing struct you add a void* super-member into your this-data and instantiate it explicitly. For any function you don't want to override you use just call the existing function function and pass in you super-data as this.
This is also safe as each subclass implementation only casts the void* this into itself which is a known struct of the same type as was last written to. You do have to split the data and keep super-class data in another struct one pointer-hop away but that shouldn't be a big issue.
I'm glad Linus still talks like this. Not because I find swearing charming, but because it turns off a certain kind of programmer. The passive-aggressive, post-flagging, code-of-conduct writer who has now become so prevalent and seeks to dominate so much of our discourse.
I'd much rather deal with an straight-forward flamer than a milquetoast, down-voting circle-jerker.
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.
Well the guy is just full of himself, and the community around him continues on to fill him up with himself every day. On other news *BSDs are mature, nice OSes with nicer communities around them (even De Raadt is better than Linus). Unfortunately I don't have time to try FreeBSD again to see if I can get suspend/resume working. But if I used a desktop I wouldn't think one bit and go with it.
>Unfortunately I don't have time to try FreeBSD again to see if I can get suspend/resume working. But if I used a desktop I wouldn't think one bit and go with it.
Suspend and Resume mostly work for me with the new drm-next-kmod drivers on an XPS-13 running FreeBSD current, it's just a little slow sometimes[1].
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.
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).
Every time I've gotten sucked into these <cough> notable LKML messages from Linus I'm not taken aback in the least.
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).
My 0,02$.
NB: my parent cussed like a sailor, certainly influencing my PoV.
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!
my credit score was below 500 before I met swifthackgenius, I had a lot of issues getting a loan based of my credit, when I wanted to get a loan at the Metro Union, they told me to pay back my debt first, when I asked for my credit report from the bureaus, I realized I have 7 hard collections and 5 inquires on my credit, I wanted to get my house and I needed help, I was searching on the blogs when I met swifthackgenius gmail dot com, he told me about the necessary process, he also got rid of the debts on my credit and raised credit score to 830. now I have my house back and I'm out of debt. You can contact him 256 743 0587 and he will be ready to assist You. I hope this helps.
183 comments
[ 1.9 ms ] story [ 363 ms ] threadPure and utter bullshit. Toilet paper up my arse.
Edit: Linus says it in public and it's just his gritty, bull-by-the-horns personality. Repeat it on an anonymous internet forum, though...(Since this is hacker news, I am guessing it’s OK to disagree on semantic grounds even when the pragmatics are clear…)
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].
[0] https://www.cl.cam.ac.uk/~srk31/research/papers/kell17some-p...
[1] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Typ...
[2] https://bugs.llvm.org/show_bug.cgi?id=31928
https://lkml.org/lkml/2018/6/5/774
Yeah Linus is the sole person who has some "intellectual tools" in a community of thousands of people.
Type one: where all the side effects are hidden behind an OS call.
Type two: Where side effects are primary and unavoidable.
People on the standards committee universally write type one code (compilers and the like). Where the Linux kernel is type two.
1. What's in practice conflicts with what the standard prescribes
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
3. He disagrees with the rationale for the change, and wants a better reason for it
(I think most of the swearing was about that)
Regardless, if standards should be questioned, then surely Linus also should be questioned. I think a better rule would be: Appealing to the standard is sufficient reason for a change, unless a good argument can be made that the standard is BS.
Yes, yes, that's Linus. Most of us have learned to get past that.
Have we really? The post is over 100+ points right now. People seem to LIKE this swearing thing Linus does.
I don't think its healthy for the general programming community. The tone that was written here is certainly not acceptable behavior on YCombinator in general. But we put up with Linus because... well... Linus is an elevated programmer and we all respect him. For better or for worse.
Also don't forget to contrast the occasional (about ~1/month) rant with the thousands of emails where he's level headed and polite.
By my count there is one f*cking, one bullshit, one shit and one arse, hardly "so much swearing". I think anyone complaining about that is way to sensitive.
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.
Ideas can be impassioned, wrong, clever, ridiculous, circular, etc. Computation shouldn't be, but often is, because, preference.
It's hard to hold all that stuff in one's head alone, and consistently feel like every time a problem is solved, a new one magically gets created, without having anyone to talk to, that really 'gets it', without that person pushing every single button you have about preference in computation.
It's an idiot way to you because you are too sensitive to it.
I could very well point out how idiotic it is to say a person is an idiot for calling other people idiots, but honestly I'd rather just laugh at the insanity computation tends to bring out in all those that have to work on computers with other people.
Irrelevant to my point.
> If you read the end of his message he's well aware that the reality of minds and ideas are flawed.
And he still doesn't work with in the confines of human social behavior.
> It's an idiot way to you because you are too sensitive to it.
And when it hinders his ability to get things done because other people think he's an asshole, I'm sure you'll still be here saying "hurrrrr durrrrr stop being so sensitive".
> I could very well point out how idiotic it is to say a person is an idiot for calling other people idiots,
If you want to think calling someone an idiot for idiotic behavior is idiotic, then you're pretty sensitive. However since I don't need you to do anything for me, it doesn't hurt me in any way to treat you like an ass.
Have you factored in the opportunity cost of being an ass for decades?
And then I get back to work using his software which I paid close to zero dollars for.
Is there another gift horse whose mouth is so frequently inspected as Linus?
> the enormous contribution to the world of a master craftsman could have been even more enormous
Hardly, it's about the contributions that don't exist from other people because of the insufferable shit-headedness of working with him. But that doesn't matter to you because we can't criticize him now can we? No, we must bend over because he is so much better than us!
I mean at least when the NetBSD group ego-tripped and removed Theo, he had the decency to work on OpenBSD.
People who really want to contribute will find a way to, always. Unless something else is more important to them than contributing.
Self serving bullshit
I've got to say, I find it really hard to take your outrage at a little mild profanity seriously if you so casually use it yourself during normal conversations. To be frank, I think you're just pretending to be offended Linus using profanity.
You both seem to be unaware, that emotional responses are not universal. A swear word in a second language and a different less sensitive culture doesn't feel like much to cause anyone to care enough to roll their eyes.
(I am merely trying to illustrate that we are all creatures of habit)
In a world in which there are only two people communicating with each other, you're definitely right that the point he is making can be made better. But consider that he just made his point to thousands upon thousands of potential contributors, because the message was shared. This directly addresses two of the things I hear open source maintainers complain about: it discourages the giving of shitty things and it moves away from the poorly scaling one on one communication.
I also feel like we see every single abrasive Linus email hauled out of context to make this point that he's an over-dramatic asshat, and not the mountain of mundane ones where he isn't torching somebody to make a point.
I take it you don't really read a lot of Linus' mail? I find it hard to believe that somebody would think that, unless they only got to see a highly biased selection of his emails.
Also, consider that we would never have had this thread in which several people are learning about gcc's documented behavior on unions if it hadn't been for the somewhat strong language. It serves a genuine purpose.
I mean, you'd get your comments flagged off HN, but other than that: it could work for you.
Unfortunately, for Torvalds, we're all in on the joke.
The problem is, well, it's just like my bulldog Reinforcements. He doesn't like hats. He sees someone walking down the street wearing a hat, he barks loudly. He barks a lot because of this. When I'm across the house and I hear him bark, I have to try to determine whether something important is happening, or just a hat. It's an impediment to our communication, me and my dog. Same with Torvalds. He sees a lot of hats, is what I'm saying.
Most of us will perk up a lot if Torvalds has something nice to say, even among the barking. Communication is complex.
You could argue that "continuing to try to affect his Andrew Dice Clay of Programming persona" isn't super clear, but it also doesn't fit "soft-pedaled politically-correct," really.
Which is wrong approach to your figuring out that. Instead, you can have only two approaches:
- learn enough about the topic discussed to have your own opinion
or
- consider how often Linus was wrong in his "expert" opinions (From my point of view, he's almost always right, but you are free to give the example of the opposite if you have them) and use that as a starting point.
Note: both approaches are completely independent of the speech figures of Linus' post, which is how it should be.
I personally, for myself, came to conclusion that most of the time, specifically for the issues I know more than enough to have my own opinion, I can trust that Linus' opinion will match my. And if it doesn't happen, that he will probably still be right and I have to reevaluate my initial opinion.
In this specific case, I would be very glad that people here try to even give some reasonable arguments why he would be wrong. Because "it's in standard" is not a valid argument, as soon as you accept that the standards definitely aren't guaranteed to be without even big errors.
The most problematic attitude I see is exactly like 'ramshorns (parallel post) asking "How can the standard be wrong" (the right question would be "where is the standard wrong"). The answer to the former:
A standard is just a document produced by a group of people trying to specify something. There's nothing that guarantees in any way that the product of any group of people doesn't contain errors.
The answer to the later: In this case, the standard "resolution" of the real need is obviously wrong, because the "resolution" is pretending that the need doesn't exist. And the need not only exists but is fundamentally necessary for the use cases where C is being used: being "low level" enough not to incur unnecessary penalties to implement something that is "natural" on the hardware level. Unions were used for decades to fulfill exactly that specific need that the standard body somehow managed to "ignore" and the compiler implementers looking for a "loophole" to produce unusable code sadly want to use. Such attitudes, both by standard bodies and by such implementers are also wrong.
edit: re tedunangst's "Linus is yelling. Do I care? Should I care? Is there any meaningful signal from the yelling" please read this my post again. I assumed I'm answering exactly this. And my opinion is really: you can assume Linus is right. He was so often right for such technical issues that it's a good start. Then, yes, care. Yes, you should, if the technical topics discussed have connection with what your work is. And if you don't program in C, and don't influence those who do, you can of course ignore the whole thing, but then the question is why are you involved now in the topic's discussion or consideration.
And for those that believe that there is really no correlation between Linus using strong language and him being rightly against some "practice," they should provide some proof that such correlation is negative or doesn't exist, as much as I know, it exists and is actually positive, exactly for some big issues I care about.
Some good reads on this topic:
https://blog.regehr.org/archives/1307
http://www.yodaiken.com/2018/05/20/depressing-and-faintly-te...
https://blog.regehr.org/archives/903 (See the end of Xavier Leroy's comment)
[1]https://lkml.org/lkml/2018/6/5/774 [2]https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux...
FWIW, having not looked at any of his LKML rants for years, he seems to have mellowed out a bit in this one.
This is kind-of a survivorship bias example.
I personally happen to like his approach in general but as I'm sure you are aware: "You can please some of the people most of the time and most of the people some of the time but this aphorism sounds a bit tired these days"
But well that problem belongs to those who work with him, so I don't care. All I wanted to say is that because he gets away with it, it does not mean that us the halflings will too, so that's not a good advice to somebody thinking of participating in the general open source sphere.
Sometimes it's worth being a bit over the top so that the entire community you are working with gets the message loud and clear. Seems like other communities (like bsd, gnome, debian, etc), often have extensive documentation, policies, and best practices... which are often ignored because every developer doesn't keep 100% of the best practices in mind at all times.
I suspect a big part of why user space is broken so rarely in Linux is exactly because Linus has made such a big deal about it in the past.
Its almost as though he identified a weak point and ameliorated it! That's what an Engineer does.
which are often ignored because every developer doesn't keep 100% of the best practices in mind at all times.
There is no such thing as best practice - that is a nonsensical phrase that I think someone involved with MS created many moons ago and caught on in IT and I absolutely despise. There is good and bad practice but you had better be very, very good at something to tell me that you know best about that something.
I do not know him personally, but people who do know him comment that he is a nice, considerate, thoughtful person.
Linus has actually chimed into this metadiscussion in the past, basically saying something along the lines of "the audience is too big and too varied to be subtle. If I am not very explicit, someone will misunderstand this, usually as an invitation to keep wasting my time" (IIRC) -- which, having managed much much smaller projects, I tend to agree with and can only imagine how much more true this is an the Linux Kernel scale.
The Finns I know are all very direct "straight shooters" - I guess that's part of it.
> That he is so is not necessarily the cause of his success, and might even be invisibly detrimental to it.
From three decades in the industry, I would say it's likely contributing to his success (though, it is independent of the cause/origin of his success, which is being smart, diligent, persistent and lucky). The ability to cut down and through bullshit is IMO fundamental, and it seems impossible to do without occasionally being rude.
It is not impossible to narrow down the complaints without being rude. Most people do that just fine, with way larger projects than his kernel.
His behaviour is just unnecessary and distracting. It's almost as if he does it for publicity or shock value. Maybe that contributes to his success, but it shouldn't.
I find it weird that people try to defend him rather than acknowledge it is just one of his character flaws. People aren't perfect, and neither is he. Doesn't take from his achievements but acting like he's in the right to behave this way is just enabling him. If people want to emulate him, they should look at the good and leave the asshole behaviour behind.
What are your examples? Please qualify project size by number of contributors and their organizational and cultural diversity.
According to [0], in 2015-2016 there were over 5,000 contributors sending patches, representing over 500 organizations (and likely, something like 50 countries/cultures/languages). Linus, through the LKML, corresponds with many of them, and has a small number of deputies. He is not paying any of these contributors, so he can't actually fire them, unlike e.g. Zuck, Jobs or Gates which, according to rumour, are/were all much less polite than Linus to their subordinates.
> It's almost as if he does it for publicity or shock value
He most definitely does, and uses it effectively. When he does, he mostly attacks ideas, not people. I've been following the LKML very intermittently, but my impression is that he is mostly kind and thoughtful in his answers while being direct. Those times that get to HN/Slashdot/Reddit/common-knowledge are few and far between, and mostly the 3rd or so response to the same thing (though, it has happened before on a "first offence").
> People aren't perfect, and neither is he. Doesn't take from his achievements but acting like he's in the right to behave this way is just enabling him. If people want to emulate him, they should look at the good and leave the asshole behaviour behind.
No one said he was perfect. Some of us believe that it is effective; call it "necesary evil", but it's one of the very few management tools that he has - basically, refusing a merge, and voicing an opinion.
I eagerly await your examples, as my experience is that people with much more management tools at their disposal are not better in this respect than Linus. Especially those examples (of "most people") that coordinate submission from 5,000 people mostly interacting directly with them.
[0] https://www.linuxfoundation.org/blog/the-top-10-developers-a...
This is wrong. He has said himself on video multiple times that his correspondents are the subsytem maintainers, which are way fewer in number (a handful of people).
[0] https://en.wikipedia.org/wiki/Linux_kernel_mailing_list
I don't get what is "necessary" with his insults. Would delivering the message calmly not be understood?
There's nothing to make anyone believe it's an "effective" strategy. Some people are deterred from contributing because this guy can't act professionally. The only reason people still want to contribute is because of the importance of the project (aka thousands of projects depend on a good linux kernel).
He can accomplish the same things, without going ballistic, in shorter time and with the respect of others earned. It's still using the same few management tools and he can retain his bad temper for when a situation actually calls for it (which is almost never). Blowing everything out of proportion is crying wolf.
Maybe he is not that bad of a person to work with. Hopefully lower than how bad Gates and Jobs were. But he sure seems to hide it well since that's all I ever hear about him. But I guess bad publicity is still publicity.
Does any of these companies run a team with 5,000 people contributing to the same codebase?
Do you have it on good authority that most of the people in IBM, Google, and Amazon that manage those 5,000 people teams are nice and polite? Because I've heard a lot about Amazon to the contrary. Do consider your selection bias: You know everything Linus tells the world, you only hear about Ballmer's chair throwing, but not any other profanities,
> Would delivering the message calmly not be understood?
Yes, he tries/tried occasionally. The wikipedia entry for LKML has more info.
> He can accomplish the same things, without going ballistic, in shorter time and with the respect of others earned
That goes counter to Linus' experience, and a few other people's.
> It's still using the same few management tools and he can retain his bad temper for when a situation actually calls for it (which is almost never). Blowing everything out of proportion is crying wolf.
Are you on the LKML? He almost never does it. You hear about it when he does. He is not shy with criticism, and he never sugarcoats anything, sure, but he goes ballistic very rarely.
> But he sure seems to hide it well since that's all I ever hear about him. But I guess bad publicity is still publicity.
You admit that you have no idea what happens between the times you hear of him. You implicitly say your model is "IBM, Amazon and Google", in which you hear nothing of how disagreements are handled, and none of which have the scale and diversity of the LKML in a single team.
It is my impression that your beliefs are not grounded in data or even anecdata. It does not make them wrong, and I'm not saying you are wrong. I'm saying you have not made any convincing argument to say you are right.
There's a very fine but very clear line in a lot of his rants between very harsh language used against solutions he doesn't like, but without making it personal, like in this case where he's attacking the rationale, and attacking the C standard, but is very explicitly avoiding attacking the people (even taking pains to point out he's not suggesting people on standard bodies in general are incompetent). The closest he comes to attacking people directly here is when he calls people who use -fstrict-aliasing "fcking morons" when* they use -fstrict-aliasing, so even that is conditional on behaviour rather than assigning a trait to the person in general. You'll sometimes see him making wide-ranging accusations about general categories of people (e.g. I remember a rant about people who think it's a good idea to do reads a byte at a time), but rarely about specific people.
On the rare occasions when he attacks people directly, I have yet to seen an example which doesn't fall in the category of either attacking persistent repeat offenders who has refused to listen to more polite rebukes (his attack on Kai Sivers being the most obvious example [1] - notably while very direct and personal, that rant was also comparatively civil in terms of actual language), or attacks that fall in the "I know you know so much better, or you wouldn't be in the trusted position you're in" category (his attack on Mauro Carvalho Chehab for a change that broke userspace [2] falls in that category; Mauro has contributed to the kernel since 2005, and have worked on it as his job for years - in this case Mauro took it on his chin, apologised for the breakage and the discussion remained strictly on topic on the technical issues afterwards).
Frankly if I'd gotten a dressing down by Linus in that category, I'd print it out and frame it, because harsh as they may be, I don't know of any case of people having gotten those without having demonstrated time and time again that they should know better first. You don't see him ranting like that at beginners. You see him ranting like that when he's disappointed because he has high expectations of you. Doesn't mean people can't get upset by them, of course, but it changes the nature of it quite a bit.
Note that I'm not saying that it's a good thing- I'm sure there'd be more civil ways to express that too -, just that I think the importance of these rants is exaggerated.
[1] http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01331.html
[2] https://lkml.org/lkml/2012/12/23/75
He swears a lot. Who the fuck cares? His audience isn't HN or The Register or anyone else not doing kernel development.
The apparent desire for bland, well-scrubbed and boring is not universal. I haven't heard of a sudden increase in demand for talk therapy for kernel devs. Lots of engineers swear a lot, and that's unlikely to change anytime soon.
Now, if you'd like to discuss actual abusive managerial behavior, we could have something to talk about.
https://satwcomic.com/bear-whisperer
https://youtu.be/dIfZKdZEJNQ
https://www.youtube.com/watch?v=z7_pVrIshxA
Kernel commits should be to a much higher standard and his way of reminding people is necessary to steer the ship.
It's easier to discuss his profanity than it is to discuss a technical topic. (I'm not unaware of the irony inherent in this very comment.)
"""
When you debug a distributed system or an OS kernel, you do it Texas-style. You gather some mean, stoic people, people who have seen things die, and you get some primitive tools, like a compass and a rucksack and a stick that’s pointed on one end, and you walk into the wilderness and you look for trouble, possibly while using chewing tobacco.
"""
Kernel developers tend to, in my experience, be a specific type of person. They are writing software that will possibly save someone's life today. Billions of dollars changing hands using their code every second.
The average programmer on HN does not write code that will see more than a couple thousand users at once. Even people at google usually don't write code as important as the linux kernel (they write on top of the kernel, usually).
---
There is also some narrativ that Linus is being abusive and I kinda disagree. Linus doesn't take a dump on people who don't know better, he takes a dump on people who should definitely know better and who are long time kernel contributors in important positions. Because these people count. (Plus, he's finnish)
Now that optimizers are getting better, these long-standing issues are starting to surface in the real world. This is no different from when programmers do something dumb like
which works until it doesn't. Or worse, someone runs Stroutroup's book through a static code analyzer and finds a wall of errors so the language is changed [1].Code around it and move on -- as in the patch mentioned.
[1] https://en.cppreference.com/w/cpp/language/eval_order
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...
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).
https://en.wikiquote.org/wiki/Linus_Torvalds
How many email messages does Linus send in a year? How many of those messages contain rants so epic they get posted here? I bet it's less 1% of all messages. Yet everyone remembers those messages and what they say. He might not be polite, but he gets his point across.
If the Swedish speaking minority of Finland is speaking anything like the good people of Åland, well, then it could be interpreted as trying to be quite polite. Never met any people who could get more obscenities into the most casual and every-day conversations then they can. It's really quite impressive.
Lets break it down.
In C, type-punning is NOT part of the language. Its technically "undefined behavior". There's an expectation that when you do:
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??)When an optimizer can assume, and when it can't assume, "aliasing" is very much an undefined behavior within the C language.
-------------
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.
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.
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.
All type punning is in the hands of the implementation. The language definition provides the syntax for it, which has the virtuel that all code which attempts to do type punning expresses it in the same manner. However, the language leaves it up to implementations to define whether type punning works, and with what caveats and restrictions.
There is some hand-waving in the definition of memcpy so that copying compatible objects is well-defined.
Yes, you can. The behavior is implementation-defined but not undefined. (Well, it can trigger undefined behavior if the value corresponds to a signaling NaN, or if the implementation uses a nonstandard, non-IEEE format for doubles that has other "trap representations". But it's not otherwise undefined.)
The basis for this is that the aliasing rule has an explicit exception for reading or writing to objects using char pointers, i.e. byte-by-byte, regardless of the object's type. This exception is in both the C standard:
https://port70.net/~nsz/c/c11/n1570.html#6.5p7
and the C++ standard:
http://eel.is/c++draft/expr.prop#basic.lval-11.8
The memcpy function is defined as copying characters, so the exception applies to it too.
Both standards also explicitly define that objects (at least of POD types) have byte representations and those representations are implementation-defined (as opposed to triggering undefined behavior if you depend on them). For C:
> Except for bit-fields, objects are composed of contiguous sequences of one or more bytes, the number, order, and encoding of which are either explicitly specified or implementation-defined.
https://port70.net/~nsz/c/c11/n1570.html#6.2.6.1
C++:
http://eel.is/c++draft/basic.types
If you memcpy a uint64_t to a double, the implementation is not required to notice that the double variable's value has changed; a subsequent access to that variable can continue to refer to a register. It's not a matter of what bit pattern was stored there.
> 3.1 > 1 access >〈execution-time action〉 to read or modify the value of an object
Thus, the requirement is symmetrical. The compiler must consider any char write as potentially aliasing a subsequent read (or write) of any type, unless it can prove non-aliasing without depending on type. And similarly, it must consider a write of any type as potentially aliasing a subsequent char read/write.
But this isn't just a person trying to properly understand the kernel code. It's someone who's trying to merge a change that's motivated by following a standard. If you're making a change to code based on a standard then yeah, you should know the intricacies of how the compiler implements that standard. Because, as Linus keeps coming back to, that's reality, that's what's actually going to impact users and other devs: the intricacies.
This change strictly makes the Linux kernel more in line with the C Standard, so it may compile better in CLang.
There's literally nothing wrong here. The code is more correct and more conformant with the C-Standard. So why is Linus against it?
Hint: he really isn't. Linus accepted the code anyway.
I dunno, the more and more I look into this, the more I feel like its just another example of Linus unnecessarily flaming someone on the developer communication channels.
This is from the overall discussion going on in this thread. Others have shown how union-aliasing fails to work in CLang throughout this thread:
https://news.ycombinator.com/item?id=17242457
By removing the non-standard GCC-specific union{} methodology from the code, the contributor necessarily improved portability to CLang. That's just the facts.
I think it's reasonable (and even important) for Linus to emphasize that the kernel is coded in GNU C, not strictly standards-compliant C.
That was super important as the compiler was first starting out, because (A) Apple's existing code was built with GCC, so it relied on GCC flags & extensions, and (B) for it to be a viable open source compiler, it needed to build large existing codebases which were already using GCC.
However, that doesn't mean that Clang will always continue to support every thing GCC does. Whether they by design or by accident, incompatibilities will arise. Of course, projects as tightly coupled to GCC as the Linux kernel might not care.
Short of converting void* (or sufficiently large ints) to T* because of legacy API, I'm not sure reinterpret_cast has any portable use. But I'm sure you can NOT type pun with it if that would break the aliasing rules.
https://docs.microsoft.com/en-us/cpp/mfc/reference/mfc-macro...
C++ has just divided the behavior of the (TYPE) cast notation in terms of more specific kinds of casts which are mutually exclusive. If a qualifier is being removed, you must use const_cast, which will not change type. The C-style-cast notation automatically chooses the right combination of C++-style casts to do the job. So for instance a C style cast from "const char " to "void ":
The same thing can be achieved with just: So the "bad" thing about the C-style cast notation then is that no matter how you change how the inputs are declared elsewhere, it will just "do what you ask", in the spirit of the C language. Whereas the C++ style casts will diagnose if the input types change so that they are not applicable.E.g. reinterpret_cast is not so powerful that it will strip away qualifiers:
If you need type-punning, use a union. Done and done.
You're just making an appeal to authority here and deciding that The C++ Standards Committee (who give us one official way to do this) is a better authority than The GCC Authors (who give us another).
And that's shortsighted and silly, because GCC (being working software) is if anything a more reliable and more accessible authority than any spec-writer will ever be. That's exactly the point Linus was making, albeit with more profanity.
Well, until you decide to use CLang, ICC, or Visual Studio or something out there. The reason why people follow the standards is because they want their code to correctly work on more than just one compiler.
Fundamentally you're still missing the point. Standards are important. Features are more important. The best standards are ones driven by features and not paper. GCC has been a far better, more innovative, and more practical driver of "standards" than any committee.
There are a lot of sharp edges to C/++ and the community really is hurting for a good static analyzer that can at least save you from most of them.
[1] almost always, because while a simple unaligned mov is safe, if the compiler unrolls and vectorises your loop, it is free to then use aligned sse read instructions, assuming that your int ptr is aligned, because pointers must be aligned according to their type. Then your program crashes, but only in optimised builds.
> So it's dangerously misleading, because lots of people have a dangerous reverence for paper over reality.
It's the same thing everywhere. You see it as "famous person said X" or "the standard is X" or "the industry does X" or "X is popular". Then you talk shit about X, because you actually know it's not right, and people dump on you because you're a heretic, or not famous, or not an authority, or don't have "a piece of paper" to quote from.
Everybody just goes with what sounds right rather than what is proven right.
I'll just throw out the corner case that sometimes that's just what you... do to get through the day. I might not give others advice on it because I don't know, but often I don't know enough and someone better says "naw that will give you trouble down the line" and stuff has to get done so I do the thing the way I was told.
Maybe I look it up later .... maybe.
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.
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.
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.
[1]: https://blog.regehr.org/archives/1307
(also hey Ted I'm a huge fan of your work, thanks in particular for threading, holy shit)
Compilers (at least clang and gcc) are smart enough to see through those memcpy's. For example:
https://godbolt.org/g/5L5PT5
That's worse though because compiler optimization are wholly unreliable. Maybe today, maybe not tomorrow. And you have utterly no control over that.
Writing to union member and reading back as another member should be okay. But it does incur copy.
https://stackoverflow.com/a/11996970
Since Linux is C, not C++, it should be fine; the author of the patch is just mistaken.
(Note that in practice, this will work in C++ too, since most compilers support both C and C++ and don't change their optimization behavior based on which mode the code was compiled in; but of course there's no guarantee this won't change in the future.)
But furthermore, this will really only work for scalars. Plus you have to go and declare a whole new type to cast things safely. It's extremely awkward.
[1]: https://blog.regehr.org/archives/959
This just highlights why strict aliasing rules exists. Because the exact same alignment problems is what you get when you type pun. Looking at the raw data as a char* or memcpy'ing it just makes it more visible that what you are doing is wrong.
The only valid reason to do type punning is to serialize data and then deserialize it back to exactly the same type. And since type puning with char* is defined as ok so there is no problem. I am having a really hard time seeing other valid reasons to do type punning and have never ever had to use it myself.
Seriously, why are people upset over strict aliasing? What is the valid use case for type punning that people are missing?
2. If you are trying to retrofit polymorphism in C maybe you are using the wrong tool for the job.
3. If you really want polymorphism you can create baseclass-struct with a void* this pointer and a bunch of function pointers as instance-functions. To "override" the struct you just instantiate it with different function pointers. If you want to inherit an existing struct you add a void* super-member into your this-data and instantiate it explicitly. For any function you don't want to override you use just call the existing function function and pass in you super-data as this.
This is also safe as each subclass implementation only casts the void* this into itself which is a known struct of the same type as was last written to. You do have to split the data and keep super-class data in another struct one pointer-hop away but that shouldn't be a big issue.
I'd much rather deal with an straight-forward flamer than a milquetoast, down-voting circle-jerker.
Suspend and Resume mostly work for me with the new drm-next-kmod drivers on an XPS-13 running FreeBSD current, it's just a little slow sometimes[1].
[1]: https://www.freshports.org/graphics/drm-next-kmod
I'd be swearing all day as well! ;-)
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).
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).
My 0,02$.
NB: my parent cussed like a sailor, certainly influencing my PoV.