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.
Film at eleven
SJW's don't eliminate discrimination. They just expropriate it for themselves.
.
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.
... all the other people over there could use such a language, even for "legitimate" reasons, and get away with it.
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.
I have NO IDEA who this Linus guy is, but his microaggressive behavior will not be tolerated in the Open Source community. I doubt he was much of a contributor to Open Source, but we need to ban him as he is creating a toxic environment in my safe space. No big loss.
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.
Two points:
a) I agree with him on the code, but I am not a competent coder myself.
b) I disagree with the form of communication and that is an area where I am competent.
As Linus expects others to write proper code, I expect people to conduct proper communication.
Same rules apply: If it does not improve the flow of information, it does not belong in the email. Some swearwords don't bring any points across that could not be covered by "professional english" subset ;-). I think "sh*t" and "crap" may be considered validly applied here. But beyond that, it generates an unnecessary conflict at rc7 time. ï
The new improved code uses fancy stuff that wants magical built-in compiler support
Imagine that. Someone thinking, "Ohhh, shiny! Let's try this because it's new and cool."
Instead of, "I need something to get the job done in the simplest fashion."
There's a reason analog light switches are still around. They just work. No bullshit about having to talk to a computer to decide what to do. Clean and simple. Just like code should be.
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
Unlike you, Linus is not a drooling moron. He knows when goto is the best tool for the job. He doesn't have irrational fears like fucked-up retards such as yourself.
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.
get by without public shaming rants
If you fuck up publicly, then the public criticism is appropriate and well deserved.
if your boss came in to the office and started ranting about a couple of admittedly bad lines in your code in front of everyone now and then, he would be fired pretty quickly
That's just flat out not true. I've worked for bosses who have done, and continue to do, far worse than anything I've seen Linus do. And guess what? They not only still have jobs, they get promoted.
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.
he GP is right, if your boss came in to the office and started ranting about a couple of admittedly bad lines in your code in front of everyone now and then, he would be fired pretty quickly.
Why should our standards be what goes on in polite office culture? (This is a quite serious question). Cultures vary and change. In the 60s it was OK to be openly sexist and racist in offices. Your argument seems to be simply that we should look at Corporate America, and that should just be our standard with no further thought.
People say Linus needs to be like that when controlling a large open source project like the Linux kernel, but plenty of other large open source projects get by without public shaming rants. Major sub-systems in Linux, for example.
Yup, and there's nothing wrong with that. Why is it you feel the need to impose YOUR standards on the world? Nobody is saying everyone else should be pricks to control open source projects if what they're doing works.
Linus isn't rascist, sexist, or anything else that's personal. He is kind of a prick when it comes to shitty code, So what?
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
Like Linus, I also write the simpler form of this kind of code when writing in C/C++.
Unlike Linus, I feel bad about it! My colleagues point out places where arithmetic overflows might lead to crashes. Honestly I find it really difficult to think through the overflow issues for *every single* plus, minus and multiply operator in my code. I think it's like cryptography in that sense -- most regular programmers, including good programmers, don't look at arithmetic operators from the perspective of attackers.
In this case, does Linus' code have the exact same behavior on all possible inputs including overflow-causing inputs? If not, which of the two behaviors is the desired one?
Are there places (maybe including this one) where the kernel code doesn't guard properly against arithmetic overflow? Will the newfound attention bring hackers scrutinizing it for overflow flaws?
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.
Not to mention that sizeof forces hlen+sizeof(struct frag_hdr) into size_t, which very probably is not unsigned int (it is not, on any of the systems I've owned for the last decade at least). Therefore overflow_usub is seriously bogus in and of itself.
"My opinions are my own, and I've got *lots* of them!"
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
If the code relies on undefined or unspecified behavior, it was working correctly only by chance, and could easily break on another platform, or another version of the compiler. It can freely use implementation-defined behavior on a given implementation.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
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.
No no. You have to do it like Linus to be effective. These gentle criticisms aren't going to cut it. Let me demonstrate
What the f$&@ is this sentence even supposed to mean? This is clearly written by a total idiot. What kind of total sh!&head would ever submit a sentence like this. Get your sh!& together and f$&@ing learn to write you worthless piece of crap.
See. That's the only way anyone learns
"In America, first you get the sugar, then you get the power, then you get the women..." -H. Simpson
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.
Yep, you are right. I accidentally the word "grows".
I have a phantom word problem where, if I think the word in my head as I write, then as I read it back, the word "appears" there, even when it isn't.
But I'm not ashamed to admit I fucked it up :P
Price, Quality, Time. Pick none. What, you thought you had a choice?
"It's literally one punch in the balls out of thousands of friendly hand-shakes per year."
Yeah, I wouldn't submit patches to him either. The GP is right, if your boss came in to the office and started ranting about a couple of admittedly bad lines in your code in front of everyone now and then, he would be fired pretty quickly. People say Linus needs to be like that when controlling a large open source project like the Linux kernel, but plenty of other large open source projects get by without public shaming rants. Major sub-systems in Linux, for example.
So the complaint is that the kernel development does everything in the open, including airing dirty laundry, while other projects keep disagreements quiet behind the scenes (at least until something is forked). Personally, I don't like to be yelled at any more than the next person, but I would prefer open and transparent.
There's zero technical reason why an "undo" function can't be added to almost any software system
I can think of a couple. It's harder to remove elements from some kinds of full-text index, especially a probabilistic index, than it is to add them. And each comment would then need revision history so that moderators can tell to what text each comment was actually replying. Do we want individual revisions to be searchable?
I'm, not defending the code, but you're missing the point:
The compiler fallback had been added:
http://git.kernel.org/cgit/lin...
The problem was the inherent unreadability of the code. Using little known compiler-specific functions makes the code much harder to read.
"I decided I could write something better than everything out there in two weeks. And I was right." - Linus Torvalds
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!"
Compilers have needs and desires, too.
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
Do or not do. There is no criticize.
deleting the extra space after periods so i can stay relevant, yeah.
If you do not know what usub is, is difficult to determine what is is doing. In that, Linus is right. But look inside the Parenthesis:
" (mtu, hlen + sizeof(struct frag_hdr), &mtu) || mtu = 7) "
Here is a very Clear OR. The guys are checking for the MTU Being to big OR too small...
Linus offers this code:
"if (mtu hlen + sizeof(struct frag_hdr) + 8)"
Which obfuscates the OR comparison...
And Both Call the label "fail_toobig" intead of a more readable "fail_MTU_outofbounds"
Or am I missing Something?
*** Suerte a todos y Feliz dia!
http://systemexplorer.net/file...
I guess we should avoid your crap, it looks like it is marked as malware. Good luck getting that removed.
APK likes to ask for responses to the same things over and over. Maybe he just likes the responses?
three
comments
together.
A his strong voice is one of the reasons Linux is so popular. I fear for the day a committee makes thedecisions
no