Slashdot Mirror
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.
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.
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.
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?
Nope.
Frankly, the purpose of the rant was to cause that piece of excrement to be replaced with something reasonable AND to give notice to other programmers that that kind of sloppy shit is not acceptable. As for those who complain that his rant was unnecessary and hurt someone's feelings, I have to ask you "Who submitted the sloppy code?" I don't see any names in the rant. Yes, I know that one could take a look at the commit logs to determine who it was, but in all honestly, I seriously doubt that anyone will. So the idiot who committed that piece of shit wasn't called out by name or publically humiliated.
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.
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.
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
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.
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.
three
together.