Torvalds: Standards need to be questioned
lkml.org
lkml.org
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.
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.
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).
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
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.
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
j = i++ * i++;
Code around it and move on -- as in the patch mentioned.
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).
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.
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.> 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.
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:
short foo[2] = {1, 2} ;
*(int*)foo = 0x12345678;
assert(foo[0] == 0x5678 && foo[1] == 0x1234);
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++:
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.
int* x = static_cast<int*>(malloc(sizeof(int))); #ifdef __cplusplus
#define strip_qual(TYPE, EXPR) (const_cast<TYPE>(EXPR))
#define convert(TYPE, EXPR) (static_cast<TYPE>(EXPR))
#define coerce(TYPE, EXPR) (reinterpret_cast<TYPE>(EXPR))
#else
#define strip_qual(TYPE, EXPR) ((TYPE) (EXPR))
#define convert(TYPE, EXPR) ((TYPE) (EXPR))
#define coerce(TYPE, EXPR) ((TYPE) (EXPR))
#endif
https://docs.microsoft.com/en-us/cpp/mfc/reference/mfc-macro...
*(int*)&foo .... *(int *)foo = 0x12345678
*reinterpret_cast<int *>(foo) = 0x12345678
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 ":
void foo(const void *arg)
{
static_cast<char *>(const_cast<void *>(arg));
}
void foo(const void *arg)
{
(char *) arg;
}
E.g. reinterpret_cast is not so powerful that it will strip away qualifiers:
void foo(const void *arg)
{
reinterpret_cast<char *>(arg); // error: stripped qualifier
}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.
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...
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.
struct Person {
char *name;
unsigned char age;
}
struct Teacher {
struct Person person;
char *subject;
}
(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:
void write32(int *ptr, int val) {
memcpy(ptr, &val, 4);
}
write32:
mov DWORD PTR [rdi], esi
ret
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.
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'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.
Yeah Linus is the sole person who has some "intellectual tools" in a community of thousands of people.
(Since this is hacker news, I am guessing it’s OK to disagree on semantic grounds even when the pragmatics are clear…)
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.
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.
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).
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'd be swearing all day as well! ;-)