Linus Rants About C Programming Semantics (iu.edu)
jones_supa writes: "Christ people. This is just sh*t," begins Linus Torvalds in his message on the Linux Kernel Mailing List. Torvalds is grumpy because some new code added to the IPv6 subsystem has created conflicts. "The conflict I get is due to stupid new gcc header file crap," he writes. "But what makes me upset is that the crap is for completely bogus reasons." The new improved code uses fancy stuff that wants magical built-in compiler support and has silly wrapper functions for when it doesn't exist. Linus provides an alternative that contains a single and understandable conditional, which looks cleaner and generates better code.
.
Such code is the result of coders who rely on the compiler too much, and their brains too little.
.
"You and I learned C when it was programmers, not compilers, which had to be intelligent."
- - - Terry Lambert
It's literally just a few rants out of thousands of friendly messages per year - and Linus only rants if crappy code comes from someone who is trusted by Linus (such as the networking maintainer here) and who should really know better.
Linus is doing his job, making sure that the Linux kernel code continues to maintain quality and supportability. I read the thread, the code is shit, and Linus called it out. I don't care about his language or the tone of his message. He's right. Linus could stomp kittens flat and I wouldn't care, as long as that kitten-stomping was in the pursuit of making the Linux kernel better. Enough of this fake controversy about Linus and his communication style, already.
You turn into Steve Jobs when you are hungry.
It's horrible, horrible code.
I'm not a C developer, but I know C and have been developing for 20+ years in various other C like languages. The thing Linus is ranting against is absolutely true. The first example is very clear what it does. Assign a variable. The second (new) code is fucked up, and completely unclear what's going on. Check some kind of boundary condition, then some weird shit going on that I don't understand?
The 3rd example is back to clarity. Check some boundary conditions, then assign the variable. I'd have never guessed the 2nd example does that without reading the 3rd.
I also happen to agree with Linus about not "toning it down". There's other ways to manage the kind of stupid bullshit that goes on in software development, but one effective way is going apeshit over shit like this. Linus's way isn't the ONLY way, but it does work. Developers tend to be filled with prima-donnas that think everything they produce is gods gift to coding. Sometimes the only way to get through is just yelling at the top of your lungs about shitty fucking code.
We live in an increasingly hyper-sensitive society where some people want to control speech in a fascist way. I'm so tired of all this bullshit about how it's "disrespectful to women", or other such crap. That seems to be the garbage dump reason for everything someone doesn't like that doesn't fit somewhere else. Just claim rascism, sexism, etc, even when it totally doesn't fit.
Oh, and please stop with the "The LEFT is trying to silence us.. blah blah blah" nonsense. This isn't "The Left" any more than the westboro babtist church are christians, or the nutjobs that open carry guns into Starbucks is "The Right". All of those are just radical elements of the political divide that have inserted themseves where they get the least criticism for their crazy ideas.
Not that this will surprise much of anyone, but the headline is wrong. Linus did not rant about C programming semantics. He ranted about a specific C function and the style used to perform a sanity check.
Seems that overflow_usub() will always be less readable than a condition then a subtraction. It's a pretty obscure function - searching for it reveals most of the discussion is about this specific patch. It will save an instruction or two with appropriate compilers, by using the JC instruction rather than a CMP/JZ and in really performance critical code this will matter, but most code benefits more from readability than that extra instruction.
Oooh, good! That joke was getting old. Nice way to milk it.
There's nothing like $HOME
This is someone you wouldn't want to work for.
Actually, I don't mind working with people who rant often, as long as they have good reason to do so.
In fact I'd rather work with people yelling at me about how shitty my code is and telling me why than a whole pasture of cows mooing about how good I am no matter what I do.
You know, ranting about pointless language additions which add to complexity for no real purpose is something Linus should be ranting about.
Shiny code for the sake of shiny code produces bloat, and frequently quit bad code.
I'm sure most coders have known someone who always put in 'clever' code which was far less good than the author thought it was.
This looks distinctly like code which is too clever for its own good.
Lost at C:>. Found at C.
but yet he allowed the crap that is systemd in the house
Linus doesn't have control over places that systemd are 'in the house'. The biggest notable chunk that would be even remotely perceived as letting systemd into the kernel is kdbus, and that hasn't been merged. Even then, I have heard arguments that it isn't particularly systemd specific. Knowing about dbus, makes me shudder about the concept of kdbus, but folks assure me I don't understand kdbus, which I confess could be true.
Linus basically doesn't have much to say about systemd today, it's beyond the scope of his attention. He has mentioned he is at least not horribly opposed to it, but neither has he gave it a huge endorsement either. He has ranted about code that came to the kernel from at least one of systemd's notable contributors, but not about the concept/project as a whole.
But all that aside, no one should treat Linus' word as the one true word of the whole ecosystem. If he loves it, hates it, or does not care, either way the larger community has to decide.
XML is like violence. If it doesn't solve the problem, use more.
Goto is a perfectly valid instruction providing you know when to use it. The typical use would be to jump into some teardown code at the bottom of a function or to escape out of some nested loop. Either way provdes more succinct and involves less code than the alternative. I assume every single kernel developer is capable of knowing when best to use it and they wouldn't have to worry about issues with c++ constructors either.
To each his own, but all in all I'd rather not work for a douchebag. Even if he's a really talented douchebag, he's still a douchebag. Real managers supervise without being an asshole.
I never understood why people do that. It's the equivalent of having the first line of your letter be on the outside of the envelope.....or the first line of your e-mail be in the subject line......
Oh wait --- car analogy required.....
It's like having the ignition switch located on the hood of your car.
Why? Because you're a delicate little flower with easily offended sensibilities?
I've worked for all types, and with all types. A little bit of "colorful" language doesn't bother me, and in many cases I'd prefer someone who can come to me and say "Hey, you fucked up, this is a pile of shit" than someone who smiles, gives me calm reassurances about my efforts, and then drives a knife into my back.
Yes, sometimes he goes a bit over the top. But in many cases, it's more a matter of the receiving party needing to grow a thicker skin.
A-fucking-men.
In my career, my skills in direct proportion to the speed at which I was criticized multiplied by directness and the skill of the other party.
As a lead, I really struggle with the special little snowflakes that need to be told how great of a job they're doing and how much they are appreciated and ... makes me want to vomit. I make sure that they either don't last long or learn to break their emotional attachment to "their" code.
Price, Quality, Time. Pick none. What, you thought you had a choice?
What the hell do you expect, "Dear Sir"?
Look, in emails, and all the way through Usenet and frigging dial up BBS systems ... the start of a thread IS the subject line.
I don't get this bitching about actually using the damned subject line for exactly what they've been used for 30+ years.
Do you expect some random salutation or other piece of text completely unrelated to the body?
We don't need a damned car analogy, we need to stop having a bunch of whiny idiots trying to redefine WTF the subject line is there for, and how it's been used for decades.
Lost at C:>. Found at C.
Hannes seems to have a valid point that boundary checking should be standardized in some way. Rasmus backs him up and mentions the result of the rant is they'll end up discarding his more comprehensive work on the issue: http://lkml.iu.edu/hypermail/l...
Linus seems to be saying all boundary checks should be ad-hoc because the new syntax is to hard to GET OFF OF HIS LAWN. Because it is dog poop.
open source world is getting overrun by high IQ morons, that put in bloat, hyped fads, and needless complexity. they indulge in mental masturbation rather than good design
Both in the technical sense and in the human sense.
Technical: People at Linus' caliber understand exactly the rules for signed/unsigned integer promotion and where underflow is defined (as wrap) and where it's undefined[1]. Consequently he wrote perfectly-correct code for detecting the underflow and bailing out safely. Programmers at mere mortal levels of skill, however, routinely mess this up, often causing exploitable security bugs (believe me, I do code security audits as part of a real honest living). My advice for everyone (contra Linus!) is always always always use the compiler intrinsics for integer math. Feel free to decline this advice if you are a Linus level wizard (if you were, of course, you would already feel free to decline it) but if you have to wonder if you are, you probably aren't.
Linus seems to think that the kernel should only be written by folks that don't need that kind of help -- and for that I won't argue with him. It's his baby and he can chose whether to have a small number of über-developers or a larger number of mortals. Which goes straight to the second point:
Human: People at Linus' caliber thrive on negative feedback. At their level, positive feedback means nothing because there's nothing he can learn from someone praising his work. He wrote a kernel, he knows he's good. Meanwhile negative feedback is useful (unless trivially discountable): if the complaint is right, he'll correct something he was doing wrong; if the complaint is wrong, he'll be forced to think through why. In any event, he could never imagine why someone would sugar-coat their opinion on any matter.
So it seems like his mode of communication is meant to answer that question for the former: he wants people of his caliber that don't write ugly code using arithmetic crutches and don't care about strongly worded criticism. There's nothing invalid about that either -- maybe it's true that the best model is that Linuses work in the kernel and the rest of us go up into userland where we use crutches like memory protection and higher-level constructs :-)
[1] And when behavior is undefined, a smarter compiler can remove the code-path entirely -- the kernel itself was hit by such a bug where GCC legally removed a NULL check because the pointer was dereferenced before the check. See also this reference. Then there's the sad fact that people still argue against the clear language rules that say that assert( 100 + some_int > some_int ); can always be optimized away.
Linux development is done on public mailing lists. Everyone knows this going in. If Linus rants about "your" code in public, he's sending a clear message.
He has passion. Snowflakes don't understand passion.
Price, Quality, Time. Pick none. What, you thought you had a choice?
To each his own, but all in all I'd rather not work for a douchebag. Even if he's a really talented douchebag, he's still a douchebag. Real managers supervise without being an asshole.
I don't mind working for a professional who holds to high standards and doesn't mind telling me when my code is crap, but I'm not going to work for a douchebag that reprimands me in front of everybody.
Professional and effective managers always reprimand in private, and praise in public. DON'T work for someone who doesn't follow that rule, life is too short.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
He already ranted about SystemD code.
the start of a thread IS the subject line.
No. The subject is a summary, or 'subject' if you will, of the post/email/missive.
That way, you can dismiss a thread based on it's subject, and not have to descend into a thread to see what it's actually about.
Get a clue before ranting, low-id.
Shame that the function used in the patch is NOT C, but instead a compiler-supplied and thus compiler-dependent feature that was put into the code in the kernel without any kind of fallback for those who don't have that compiler (e.g. an equivalent header that defines it if it's not already defined).
And Linus' equivalent alternative is valid C99 that works on all compilers, and does EXACTLY THE SAME while being slightly more readable.
Otherwise you might indeed have had a point to make.
Part of the reason is this: while it's provable that you can use ifs and whiles to eliminate all gotos, the proof also demonstrates that code-length may grow exponentially in the number of gotos eliminated.
"My opinions are my own, and I've got *lots* of them!"
KICC = Keep it Complicated and Crappy
I recently ran into a similar example in Java, where Java 8 has introduce the class java.util.Optional. This is used by certain other Java 8 classes as a return type.
What does Optional do? It provides an object that contains an object. If that inner object is null, the method isPresent() returns fall. So now, instead of:
if (widget != null) { widget.doSomething()) ... }
You can write
if (optional.isPresent()) { widget = optional.get(); widget.doSomething()) ... }
Of course, if you don't quite trust the class giving you the Optional, you get to write
if (optional != null && optional.isPresent()) { widget = optional.get(); widget.doSomething()) ... }
This serves no useful purpose, except to make code more complex. Stupid, stupid, stupid...
The claim, of course, is that this marvelous class is designed to work with lambdas. The thing is, lambdas themselves are an idiocy in Java. Lambda expressions are inherent in purely functional languages, but they are semantically out of place in a declarative language.
Enjoy life! This is not a dress rehearsal.
Oh young one.. There is a basic level of human decency and professionalism which we all do well to maintain. Unfortunately this is a rare quality in many organizations these days.
I suspect that if your boss called your efforts crap in full ear shot of your peers, even if he was correct, you'd be a bit miffed at him/her for embarrassing you in public. It may change your behavior, but it also will change your attitude to them due to being rudely treated. Most folks have issues when they "loose face" in public and a wise professional manager avoids creating issues when possible. It only makes sense to go out of your way to avoid offending others, even in circumstances where you don't think you should have to bother. Wise people bend over backwards to avoid creating problems, trust me.
For instance, as a software developer in a large organization, I ALWAYS assume that any software problem I find, or get's reported to me is MY FAULT, even when it's not. I will either *fix* the problem, or if I cannot do that, I will enlist others to "help me" figure out how to fix it. I never say "See, it's your problem to fix." but keep showing them the evidence and asking them how I can fix it. When it is their problem, they will eventually realize this but because I've not been rubbing their nose in it I don't have to fix the relationship the next time something rolls around. The other option is to just shoot your coworkers full of holes, and the first time you are wrong about who's at fault it was, you are the hard nosed worker looking to get out of responsibly.
Do I have to do this? No, but it establishes you as the guy that knows your stuff, who is willing to work with others on stuff that's not his responsibility and exposes you to details from the larger picture. You are the nice hard worker that everybody trusts.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
I have to agree. I was ready to read a melodramatic rant over slightly new semantics, but I instead found a completely justified and reasonable criticism of horribly unreadable (and kind of broken) code. With some extra swearing thrown in for Linusness.
Remember, coders, if you're doing anything with code that will be used by others or reused by you, readability is crucial. I'm not talking about comments unless the code itself needs to be less readable (e.g. Performance in a hot spot). I mean the code itself.
And, by code that others may use or you may re-use, I mean all code.
Do or not do. There is no criticize.
deleting the extra space after periods so i can stay relevant, yeah.
three
comments
together.