back to article Linus Torvalds fires off angry 'compiler-masturbation' rant

Linux Lord Linus Torvalds has unloaded as only he can in a post to the Linux Kernel Mailing List. At issue is some new networking code that popped up in what was hoped to be the final version of Linux 4.3. Torvalds' first words on the code were: Christ people. This is just sh*t. Torvalds is grumpy because some new code has …

  1. Rol Silver badge

    He's blunt. He's aggressive. He's offensive.

    He's right.

    And thank heavens he still cares enough about his baby to kick ass when needed.

    1. Lee D Silver badge

      Re: He's blunt. He's aggressive. He's offensive.

      He's not corporate either, he has no need to be polite.

      In professional atmospheres, I've witnessed a whole lot worse than "what is this shit?". Privately, I've heard even high-end corporate types use such languages in private meetings - they are only more polite for fear of some HR-comeback if they're not. In everyday personal life, I sure give such verdicts on crap that I'm forced to use.

      I'm more interested in why anyone thinks this is worthy of an article. "Elite software developer gets pissed off at crap software code foisted upon him".

      What gets me is that a few messages later is a re-pull request without that code - so it's entirely unnecessary, unjustified and only creeped in (if the new pull request is to be believed) because nobody commented on it when it was posted to the usual mailing lists. This is a heads-up to his maintainers, and the people posting patches, and those reviewing patches. "We don't do this".

      And guess what? I bet nobody's going to try pushing that shit into the kernel again.

      1. Naselus

        Re: He's blunt. He's aggressive. He's offensive.

        "I'm more interested in why anyone thinks this is worthy of an article. "Elite software developer gets pissed off at crap software code foisted upon him"."

        I suspect the 'newsworthy' part of this is actually how restrained Linus was in his rant this time. After all, nothing caught fire and women and children didn't run screaming.

    2. Chika
      Linux

      Re: He's blunt. He's aggressive. He's offensive.

      If some of the people behind this code weren't such doofuses, then maybe he wouldn't have to be.

      Go for the jugular, LT!!!

    3. The Tea Lady
      Unhappy

      Re: He's blunt. He's aggressive. He's offensive.

      It's small wonder that GNU/Linux is going the way of the Blackberry! It's run by people who act like little children! Nay, worse than children.

      Incivility is rarely appropriate and never constructive. Much better ways exist to get one's point across, without resorting to such tawdriness! And anyone defending such antics deserves equal blame.

      Besides, in a few years, GNU/Linux will go the way of the Blackberry. And small wonder, that.

      1. Paul Smith

        Re: He's blunt. He's aggressive. He's offensive.

        For example ?

      2. Amorous Cowherder
        Stop

        Re: He's blunt. He's aggressive. He's offensive.

        "Incivility is rarely appropriate and never constructive. "

        Oh shut up! Yes, I do agree but sometimes you have to vent, clear the air make people aware of your emotions THEN most of us will apologise and get the thing fixed.

        Sorry but despite us have having this noble air of civility, we're all just monkeys with technology. The killer instinct is just below the surface in every single one of us and it's only the brainwashing we get in our familie, schools and social circles that helps us to keep it under control. Once in a while it bursts out, we break something, shout and scream and then we get back to normal.

        1. BillG Silver badge
          Pirate

          Re: He's blunt. He's aggressive. He's offensive.

          Sorry but despite us have having this noble air of civility, we're all just monkeys with technology. The killer instinct is just below the surface in every single one of us and it's only the brainwashing we get in our familie, schools and social circles that helps us to keep it under control. Once in a while it bursts out, we break something, shout and scream and then we get back to normal.

          Although I don't like what you wrote, I'm forced to agree with it.

        2. Anonymous Coward
          Anonymous Coward

          Re: He's blunt. He's aggressive. He's offensive.

          Yes, I see your point, I slapped a couple bitches around and then killed their boy friends but now I feeling fine again, boys will be boys ;)

      3. JustNiz

        Re: He's blunt. He's aggressive. He's offensive.

        You "politically correct at all cost" types make me wanna puke. How is this incivil? he's insulting the code no the author. The code IS crap and he's pointed that out with the force it requires to nip it in the bud and stop some moron copying that approach again later.

      4. JustNiz

        Re: He's blunt. He's aggressive. He's offensive.

        >> It's small wonder that GNU/Linux is going the way of the Blackberry!

        Wow how uniformed can you be? You need to go get a clue.

        Guess what OS over 99% of the worlds 500 top supercomputers run? Guess what OS is the parent of what most of the world's smartphones run? Guess what OS Google and most of the other servers on the internet run? Guess what OS your own home networking gear is probably running?

        1. sansmojo

          Re: He's blunt. He's aggressive. He's offensive.

          Blackberry? ;)

      5. ro55mo

        Re: He's blunt. He's aggressive. He's offensive.

        It's open source development. Licensed under GNU GPL. Pray tell how it can go the way of Blackberry? It is not even a company...

        Sure other people have formed companies which have created products based Linux like Redhat, VMware and Canonical to name few.

      6. Dolapevich

        Re: He's blunt. He's aggressive. He's offensive.

        I... can't imagine why you would say this.

        You are not only comparing apples with cyclotrons, which doesn't make any sense, but also giving no clue of why you do it.

      7. Anonymous Coward
        Anonymous Coward

        Re: He's blunt. He's aggressive. He's offensive.

        > in a few years, GNU/Linux will go the way of the Blackberry

        And replaced by what?

    4. JDX Gold badge

      Re: He's right.

      Sometimes he's right, sometimes it's subjective personal opinion.

    5. Christian Berger Silver badge

      Yes, but it may be one of the few cases of him being wrong

      There's a rather good argument that he's wrong. Essentially using the compiler built-in function is more efficient and in a way more readable as everybody understands what this code is about. (checking for an overflow)

      Overflows are one of the hard parts of C(++/#) and even Java.

      Here is the full argument by someone who professionally finds integer overflows:

      http://blog.fefe.de/?ts=a8c95274 (In German of course, this is about computing after all)

      1. Michael Wojcik Silver badge

        Re: Yes, but it may be one of the few cases of him being wrong

        There's a rather good argument that he's wrong.

        I don't think it's a zero-sum game in this case. The code he's complaining about is not particularly readable; I'm with him on that. And using language extensions is suspect, in my book, but then I've never been fond of Gnu's "almost but not entirely unlike C" language.

        On the other hand, his proposed alternative, while very clear, duplicates the addition and so risks skew - in a future edit, someone might change one line but miss the other.

        The broader point, that checking for over/underflow in C is a pain in the ass and easy to get wrong, and at best makes the code more verbose and harder to read, is well-taken. This is one of the real problems with C: making it safer is possible, but expensive both for the author of the code and anyone reading it later (and some studies put reading and understanding code at as much as 40% of the overall cost of typical software development).

      2. gnasher729 Silver badge

        Re: Yes, but it may be one of the few cases of him being wrong

        Linus' code is straightforward and obvious for any decent C or C++ developer. The code using macros is unreadable and trivial to get wrong, because it relies on knownledge written elsewhere.

        1. bazza Silver badge

          Re: Yes, but it may be one of the few cases of him being wrong

          Ironically no one seems to be checking for overflow of:

          hlen + sizeof(struct frag_hdr)

  2. John Tserkezis

    Beats the shit that's beaten into Microsoft software people "Make money at all cost! Make money at all cost!"

    1. Anonymous Coward
      Anonymous Coward

      beaten into Microsoft software people "Make money at all cost!

      Well, Windows 10 says the beatings didn't work.

      I've no doubt that if MS had been taken private by somebody like Silverlake (a private equity outfit focussed on IT for those not familiar) then W10 would have been very different, would have been a winner, and we'd (happily) have been reaching for our wallets because no way on this planet would it have been free.

      Maybe I'm alone on that, but on balance I would have payed for W10 if it had worked. So a choice of a pure tiles'n'apps or W7 menus according to my choice, ideally some new whizzy tech to justify the price (that is, not crapware like Cortana), no spyware, better security (including a complete ban on security ground-zeroes like Flash) and all for a cost of around thirty quid.

      But Microsoft don't see this. W10 will be rammed down our throats (and when pressure doesn't work, they'll just end-of-life W8 to force us), but speaking for myself, I can smell a couple of things. One is the smell of decay (I thing somewhere Redmond way), and the other thing I can smell is mint. Linux Mint. I'm not there yet, but Microsoft are pushing and pushing, and eventually my patience will give way. I just needed to replace a domestic laptop, and I've ordered a Chromebook. I know that's Google spyware, but the point is that it's the first non-Microsoft computer in this household in nigh on thirty years.

      1. Anonymous Coward
        Anonymous Coward

        Where I work, we have a department exactly like that. Good thing that the mortgage is paid off soon.

      2. PaulFrederick

        Mint is not the highest quality Linux distribution. So don't judge all of Linux by Mint if you ever end up running it. Although Mint has a lot of features that do make it new user friendly. Mint is akin to your first bicycle with training wheels on it. Once you get your balance you might want to try out a distribution with a more mature orientation. By then you'll know which to choose.

        Now as far as spyware goes everyone is spying on your as soon as you access the web. So I don't know how much Google spying on your some more really matters. Have a cookie.

    2. JDX Gold badge

      MS spends huge amounts of money reviewing their code. Their process is FAR more rigorous than some angry git personally checking all the code ;)

      1. JustNiz

        Yes they do ...and in spite of that, Windows is still undeniably more insecure than Linux and much more of a shit product generally too.

        1. Siv

          I think this tired argument about Windows being "undeniably insecure" is wearing thin.

          In reality Windows is now pretty secure, sure it was insecure 10 years ago, but now as each vulnerability has been patched the malware writers are having to attack things like Java and Flash as it's increasingly difficult to attack Windows itself.

          The old claims about FOSS being inherently secure because it is open and that means more eyes were able to look over the code has been debunked lately. I am thinking of the likes of OpenSSH/Heartbleed and TrueCrypt and the number of viruses that are appearing on Android.

          The truth is, (shock horror), that whilst few end users were using Linux and thus it was not worth the malware writers attention it seemed secure. Now that finally it's going mainstream in its Android form and there are substantial amounts of end users with Bank Accounts to hack, suddenly we are seeing the true facts that Linux like Windows is written by mere mortals and there are just as many bugs as Windows had.

          1. Oldbear

            In reality Windows is still pretty insecure, check the US_CERT database. Firmly holds the record for score 10 vulnerabilities. Closely followed by IE. Adobe is lagging behind...

      2. PaulFrederick

        Judging by performance data apparently whatever Microsoft is doing isn't working well for them. That angry git even wrote Git in his free time.Git is another project Linus was the founder of.

    3. dogged

      > Beats the shit that's beaten into Microsoft software people "Make money at all cost! Make money at all cost!"

      Oh, do you work for them?

  3. Mugs

    Good to see GOTO is still cool.

    1. Anonymous Coward
      Anonymous Coward

      GOTO is fine in very select circumstances. i.e. (and the forum code will make a mess of indentation here)

      int init_structure(struct my_structure** s)

      {

      int ret = 0;

      *s = malloc(sizeof(struct my_structure));

      if (!(*s)) {

      ret = errno;

      goto exit_init;

      }

      *s->substructure = malloc(sizeof(struct another_structure));

      if ((*s)->substructure) {

      ret = errno;

      goto exit_init;

      }

      free(*s);

      *s = NULL;

      exit_init:

      return ret

      }

      Yes, that GOTO could be factored out quite easily in this situation, but suppose you had not one, but three or four sub-structures to allocate? Then an IF-based solution becomes messy. GOTO actually works out clearer to understand. Easy to read code is easy to debug code. There's no spaghetti here!

      What's not okay is jumping between labels in other functions or using it to replace if, while and for statements. The C language has things like setjmp and longjmp for doing exactly this, and it's one feature that to my mind is just asking for trouble, so I never use that feature. That's what leads to a big tangled mess that no one can understand.

      1. boltar Silver badge

        setjmp and longjmp are essentially the C version of exception handling and save doing if-then checks on returns of nested functions. But they're really only for use when things are really in a mess and unrecoverable - as exceptions should be used rather than as a general function return method which is what seems to happen in C++ rather too often due to poorly written libraries and ignorant coders.

      2. This post has been deleted by its author

        1. Def Silver badge

          You're leaking this...

          No he's not. At least, not in that function.

          1. sed gawk

            @Vic is correct, OP is leaking.

            The code jumps to the error path when substructure *is* allocated, then it frees the parent, leaking, substructure.

            if ((*s)->substructure) {

            goto err_fail

            ....

            err_fail:

            free(*s); // leaking ((*s)->substructure)

            1. Electron Shepherd

              It's not a leak. If the sub-structure allocation succeeds, the goto just after it is there to skip round the free. The free is only called if the first malloc succeeds and the second fails, and in that case, you want to free *s but not the sub-structure.

              Having said that, the confusion caused by a supposedly simple example of how to write good code with gotos is a shining example of why most people steer clear of them.

              1. sed gawk

                Fair cop, I misread it.

            2. Vic

              Vic is correct, OP is leaking.

              No I'm not - I misread the sense of the allocation test - it changes betweent the two mallocs. The goto is on successful allocation for the second one. I should look more carefully next time.

              Although I don't make hard-and-fast rules about the use of goto, I think this is a case where it really shouldn't be used...

              Vic.

              1. sed gawk

                Mea culpa, I made the same mistake.

      3. Def Silver badge

        And I don't agree with using GOTO. Ever. In the last 23 years of C* and C++ programming, I've never felt the need to use one.

        Nesting things together is much preferable in my opinion. Yes, you can potentially have many levels of nesting, but...

        1) If it's getting too crazy, split things up into smaller functions.

        2) we live in an age where 24 inch wide screen monitors have been the standard for any office for at least the last 10 years. So we really should move on from limiting lines to 80 characters - something I've never ever believed in, and will never do unless I have to. Artificially splitting lines of code makes things much harder to read, not easier.

        3) it allows you to write code that cleans up exactly what needs to be cleaned up before exiting without having to have hundreds of checks all over the place to determine how far you actually got.

        and 4) static branch prediction assumes IF statements are true, so if you're checking for the error condition more than the success condition, the chances are your code will be stalling and flushing the instruction cache more than you're performing actual real work.

        int init_structure( struct my_structure** s ) {

        *s = malloc( sizeof( struct my_structure ));

        if ( *s ) {

        ( *s )->substructure = malloc( sizeof( struct another_structure ));

        if(( *s )->substructure ) {

        return 0;

        }

        free( *s );

        *s = NULL;

        }

        return errno;

        }

        *I haven't actually used C in over 15 years, and seriously hope I don't ever have to again. It's a terrible, insecure language that should have been donated to a museum a very long time ago.

        1. Suricou Raven

          Goto has some niches.

          In C, there is never a strict need to use goto. Anything that does need goto can be rewritten without using it - this can be proven mathematically. C without goto is still turing-complete.

          But it can sometimes be cleaner - a single goto can take the place of a chunk of code repeating twice and taking brackets five levels deep. Some consider the goto to be a tidier option.

          1. Carlie J. Coats, Jr.

            Re: Goto has some niches.

            It can also be proven that in the worst case, code length grows exponentially in the number of GOTO's eliminated.

            FWIW

          2. JustNiz

            Re: Goto has some niches.

            Code with gotos in it is far more brittle and will lead to far more unexpected side effects from making changes.

        2. Tromos

          @Def

          C is only ever a terrible, insecure language in the hands of a terrible, insecure programmer.

          1. dajames Silver badge

            Re: @Def

            C is only ever a terrible, insecure language in the hands of a terrible, insecure programmer.

            Maybe ... but Sturgeon's Law applies.

          2. smartypants

            Re: @Def

            This is wrong.

            Even very good c or c++ developers make errors that can be security holes. All you can say is that they are less likely take them, which isn't really good enough. These languages often silently hide these flaws, ripe for exploitation later. Lots of tools help identify the flaws, but it's a lot of effort.

            It's the 21st century and we still have languages that demand perfection from flawed humans. No wonder this site is stuffed with exploit news.

          3. Def Silver badge

            Re: @Def

            C is only ever a terrible, insecure language in the hands of a terrible, insecure programmer.

            In my experience, most programmers are sloppy at best, and downright dangerous at worst. We are only human at the end of the day, and we all make mistakes. As the comments (and down votes) regarding my earlier reply to Vic where he incorrectly thought that the quoted function was leaking memory quite aptly points out. And that was a simple little function that should have been simple to read.

            There's a reason the vast majority of the world* doesn't use C any more: Programmers make mistakes. Modern languages, in recognition of that fact, attempt to make it as hard as possible for a programmer to screw up - certainly in such obvious ways. C is not a modern language. It's not even close. I'm not sure I'd even class C++, the language I've used for the last 16 years (since moving on from C), as modern either. It has some modern features, but at the same time still gives programmers plenty of opportunity to screw up. (The more cynical developers out there might argue C++ allows you more opportunity to screw up than C does, but that's a discussion that I will willing have over beers another day.)

            *what percentage of job adverts are for C developers these days?

            1. bazza Silver badge

              Re: @Def

              @Def,

              "Modern languages, in recognition of that fact, attempt to make it as hard as possible for a programmer to screw up - certainly in such obvious ways."

              Cough Javascript cough...

              1. Def Silver badge

                Re: @Def

                Cough Javascript cough...

                hah, well... yes. :)

                And PHP. And probably a dozen other languages that have their origins in the web. :)

          4. Wilco

            Re: @Def

            Not true. C requires constant vigilance for buffer over/underruns, arithmetic overflows pointer aliasing etc etc, all of which can occur in C code without any compile time or run time warning. Other languages have features that reduce the impact or interrupt control flows when these things happen. Unfortunately most of them aren't very suitable for writing OS kernals.

        3. Anonymous Coward
          Anonymous Coward

          How to lose arguments on the interwebs.

          "And I don't agree with using GOTO. Ever. In the last 23 years of C* and C++ programming, I've never felt the need to use one."

          Never use how long *you* have been doing something as a way to show how bad ass you are at it. Especially when you then go on to say you haven't done it in the last 15 years...

          There are groups of people that have been doing something they are sure is the correct and totally right way of doing things for thousands of years that are undeniably wrong.

          Have you ever used break in a loop? Well you just used a goto to the outside of the loop. THE HORROR!

          1. dajames Silver badge

            Goto vs Break

            Have you ever used break in a loop? Well you just used a goto to the outside of the loop. THE HORROR!

            I've heard that argument many times before, but it doesn't hold up.

            Sure, a break statement in C is semantically equivalent to a goto whose destination label immediately follows the loop. That doesn't mean that the two are equivalent in all ways: the break statement is self-documenting. You know as soon as you see it what it's doing and where it'll jump to; with goto you know none of that without examining the code and finding the label. The code with the break statement is more readable and more maintainable than the equivalent using goto.

            So, even when it's doing something unexceptionable like jumping out of a loop the goto should be considered harmful when compared with break. In other cases it can be far more harmful.

            1. Anonymous Coward
              Anonymous Coward

              Re: Goto vs Break

              >That doesn't mean that the two are equivalent in all ways: the break statement is self-documenting.

              if(failedatargument):

              goto packupandgohome;

              It's almost like you can give the label a sensible name so that it describes what the code at the label does.. almost as if it's called a label for exactly that reason.

              1. MassiveBob
                Joke

                Re: Goto vs Break

                Goto HELL is all I seem to get out of my missus these days.

                Maybe it's time to Break the relationship to escape this loop??

            2. Simon Harris Silver badge

              Re: Goto vs Break

              "You know as soon as you see it what it's doing and where it'll jump to; with goto you know none of that without examining the code and finding the label."

              That all depends on how much code there is between the break and the end of the loop, and whether the blocks within that section have been indented consistently and correctly - it might just be faster to find the label than have to count the opening and closing braces that follow the break.

              (that's not to say I'm condoning using gotos and untidy bracing!)

            3. Michael H.F. Wilkinson Silver badge
              Coat

              Re: Goto vs Break

              Come on you guys, give goto a break

              Sorry, couldn't resist. I'll get my coat. The one with that Kernighan and Ritchie book in the pocket please

            4. Yugguy

              Re: Goto vs Break

              10 Print "hello world"

              20 Goto 10

              I win.

            5. Anonymous Coward
              Anonymous Coward

              Re: Goto vs Break

              break can be hard to spot where your code winds up too, it depends on how big the loop is or how deeply nested it is.

              There are other features of C that can make code hard to read. Sometimes there are good reasons why something is written a particular way. One bit of code I'm not particularly proud of in terms of its looks is this:

              https://bitbucket.org/vrtsystems/pyregblock/src/1bb36223780687b07c94820ada8052f25171f0ab/regblock.c?at=master&fileviewer=file-view-default

              No, not pretty, abuses the C pre-processor something fierce, but it works (on x86, AMD64 and ARM at least), and gets the job done. Crucially, the macro is written once, then instantiated several times to give me code that operates on 8-bit, 16-bit, 32-bit and 64-bit integers.

              This was done to avoid writing the same thing multiple times. C++ was another option, but I wasn't sure how to go about gluing Python's C API and C++, whereas macros at least got the job done.

        4. Adrian 4 Silver badge

          "And I don't agree with using GOTO. Ever. In the last 23 years of C* and C++ programming, I've never felt the need to use one."

          Then you're a fool. It's there for a reason, and one day you'll find it. Never say never.

          "*I haven't actually used C in over 15 years, and seriously hope I don't ever have to again. It's a terrible, insecure language that should have been donated to a museum a very long time ago."

          Languages aren't insecure, people are. Again, use the right thing for the job and ditch the prejudice. There's no such thing as a language that's good for everything, and one that tries to force its users to write secure code by removing all the best features is going to burn sooner.

        5. dajames Silver badge

          Line length

          we live in an age where 24 inch wide screen monitors have been the standard for any office for at least the last 10 years. So we really should move on from limiting lines to 80 characters

          Long lines are hard to read -- regardless of our ability to display them intact -- and that has an effect on code clarity. Somewhere around 80 characters is the upper limit for optimal readability, so while I dislike hard limits I would hope not to see many lines longer than that in a decent codebase.

          1. Carlie J. Coats, Jr.

            Re: Line length - actually, 60-72

            Actually, the human-factors people tell us that line-length in the range 60:72 is best; readability is (slightly) degraded at 80. (By this I mean line-length exclusive of indentation: a line using columns 24-84 is basically as readable as one using columns 0-60.)

            And I REALLY HATE web-presentation that forces lines longer than 120: their stuff is TOTALLY unreadable. (Some of IBM's documentation fails this way; they should know better ;-( )

          2. JHC_97

            Re: Line length

            With one notable exception sql Strings in java. Ripping out the " + so you can put it in a proper tool for explain is a right pain. If its on one line its easy.

        6. Steve Gill

          *2) we live in an age where 24 inch wide screen monitors have been the standard for any office for at least the last 10 years.*

          I wish, At most of the sites I've worked at in those same 10 years large monitors are only for managers and users - developers have to make do with the cheapest 14 or 15 inch monitors available :(

        7. E 2

          @Def

          "*I haven't actually used C in over 15 years, and seriously hope I don't ever have to again. It's a terrible, insecure language that should have been donated to a museum a very long time ago."

          C is the minimal no-BS model of a load store machine, which is why all the big kids play with it. All we are really doing is loading registers then doing ops then storing results, regardless of the language used.

          You could say all the other languages are just wrappers around C.

          If you cannot avoid shooting yourself in the foot, perhaps you should not be allowed to play with guns.

        8. gnasher729 Silver badge

          By using *s all over the place instead of just assigning the final result to it, you make your code unreadable, error prone, and inefficient.

          What's worse is returning a separate error indicator, with a function name that makes it absolutely not clear how that error indicator is to be interpreted. Instead of the obvious way to return the pointer. What's good for malloc is good for me.

      4. sed gawk

        int init_structure(struct my_structure** s)

        {

        enum { eAlign = 7 } ;

        size_t aligned_size, total_space;

        char *base;

        aligned_size = ((eAlign+sizeof(struct my_structure)) &(~eAlign));

        total_space = aligned_size + sizeof(struct my_substructure);

        errno = 0;

        base = calloc(total_space,sizeof(*base));

        if(!base)

        return errno;

        *s = (void *)base;

        *s->substructure = (void *)(base + aligned_size);

        return 0;

        }

        1. cambsukguy

          One of the worst parts of python lint, 80 character lines. Hateful. Otherwise fab language.

          As for the 'C' without goto; the indented code method is the way I always did it too.

          Readable, obvious, more testable - easy for humans to track and most importantly:

          One function exit, just one - allows easy test/debug instrumentation macros etc.

          1. Anonymous Coward
            Anonymous Coward

            80 character lines is not bullshit, it is still relevant today. More text than that on one line is not as legible, and encourages people to make convoluted statements that would be clearer if set on multiple lines.

            With today's massive monitors, this doesn't mean that you have lots of wasted space, it means you actually have space for contextual information around your editor, eg man pages, other source files, other resources..

            One of the worst parts of python lint, 80 character lines. Hateful. Otherwise fab language.

            Waah (its actually 100, but whatever). Put max-line-length in your pylintrc and dry your eyes.

            1. Suricou Raven

              Python? 80-character limit is a lot older than that. Try FORTRAN.

              And FORTRAN's 80-character limit is for a very practical reason indeed: That's as much as you could fit on ye olde punch card.

              1. allthecoolshortnamesweretaken Silver badge
                Pint

                80 characters per line / FORTRAN / punchcards

                You beat me for it - have a pint!

                1. swm
                  Headmaster

                  Re: 80 characters per line / FORTRAN / punchcards

                  72 characters actually. The 704 couldn't read all 80 columns as it was row binary and a 36-bit machine.

                2. Herby Silver badge

                  Re: 80 characters per line / FORTRAN / punchcards

                  Actually there is another reason for 80 character lines:

                  If you use nice American letter paper (8.5 inches wide) and print out at 10 characters per inch (common for nice line printers, like an IBM 1403), you use 8 inches of space for the output lines.

                  So, if you DO document things and print them out (a good idea in my book), 80 character lines and MONO spaced type are nice to have. Sure there are smaller fonts, but as you advance in age (like me), you tend to prefer the nice 10 character/inch type on nice letter paper.

                  In the older days, you used the same output, but used blue (green) bar paper which was 14 inches wide and 11 inches long, and it had lots of room for the scribblings you made while doing the developing. (been there, done that!).

                  So, 80 character input lines are a nice thing to have.

                  1. rampersand

                    Re: 80 characters per line / FORTRAN / punchcards

                    ❝ [...] and it had lots of room for the scribblings

                    ❝ you made while doing the developing.

                    Oh god! I read that and had a flash of memories hit me. I usually used the 8x11" white dot matrix or daisy printer paper rather than that green lined stuff, but when I ran into a difficult to figure out problem, or I was going to be away from the computer for a while, I would print out my code, and spend hours looking at hard copy, adding notes, rewriting in the margins, crossing out lines of code or variables... Sometimes just having a hard copy that you could flip through the code by pulling pages up accordion style to compare different sections made everything clearer. Sometimes seeing it like that made me realize I could combine several chunks of code into one elegant short piece of code. I really should get back into the habit of printing code like that — so many great solutions and ideas were spawned from it.

                    I had forgotten all about that until I read your comment. The wave of suddenly remembering all that at once was a weird feeling (in a good way).

              2. My Coat

                I'm pretty sure the line length limit in the FORTRAN f77 I used as an undergrad in the 90s was lower than 80 characters. You lost the first 6 or so characters on every line (okay, they weren't really lost, but they had specific meanings so for most lines of code they weren't used), and I'm pretty sure everything after character 72 was ignored, no?

                1. allthecoolshortnamesweretaken Silver badge

                  FORTRAN77 / uni / mid 1980ies: We had to use the last 3 characters on each card (later, on the terminals in each line) for putting in our initials. Made it easier for the prof to review our code, i.e. to check who wrote what.

              3. Anonymous Coward
                Anonymous Coward

                "That's as much as you could fit on ye olde punch card."

                IIRC the last columns on a card were for the card number - with possibly a "continuation" indicator in column 72? The numbers were usually spaced in 100s so that added cards for corrections could be slotted in using 10s for the first change - then finally 1s before part of the pack had to be duplicated and renumbered.

                It was not unusual to drop a block of cards on the floor - then using the card numbers to get them back into order. There were three common errors:

                1) Taking too big a handful of cards out of the tray - and the centre "blew out".

                2) Forgetting the back end of a full tray of cards was balanced over the edge of a work surface. At the critical unloading point the cards left in the tray had a critical centre of gravity - and the tray did a backward flip scattering its contents over the floor.

                3) Forgetting to put the "lid" on the high speed card reader's vertical output hopper. The read cards were sprayed into the air.

                1. Doctor Syntax Silver badge

                  @A/C & @My Coat

                  Close.

                  1-5 were for labels - for GOTOs. The continuation character was in 6. 73-80 were sequence numbers.

                  1. BoldMan

                    Closer!

                    column 1 was a page/line feed character

                    columns 2-5 were for label numbers

                    column 6 was continuation character

                    columns 7-72 were for code

                    columns 73-80 were for card number or some other purpose I can't remember just yet...

                    1. Hi Wreck
                      Facepalm

                      Re: closer

                      The last 8 columns were for the sequence number so that after you dropped the card deck on the floor you could run the mess through the card sorter to get your program back.

                2. This post has been deleted by its author

                3. This post has been deleted by its author

              4. cpage

                Fortran has not had an 80-character line length limit since 1990 - currently 132 characters.

              5. This post has been deleted by its author

            2. Charlie Clark Silver badge

              80 character lines is not bullshit, it is still relevant today. More text than that on one line is not as legible

              That's not quite true. Line lengths of about 120 chars are fine which is why paperbacks use them. But 80 chars is generally enough for most lines.

              The 80 chars come from the terminals used in the 1970s and the practice of distributing patches via e-mail where additional line breaks could cause problems. It's stayed around because readable diffs are so important.

              80 chars isn't a hard limit in Python and I don't know any people who use something like lint to enforce it. PEP 8 is the main set of rules, wisely reminding us that "foolish consistency is the hobgoblin of tiny minds".

              1. Doctor Syntax Silver badge

                "The 80 chars come from the terminals used in the 1970s"

                But the terminals were following on from the card widths of earlier days.

              2. Tom 38 Silver badge

                That's not quite true. Line lengths of about 120 chars are fine which is why paperbacks use them. But 80 chars is generally enough for most lines.

                Hmm, only nasty cheap paperbacks. In print typography, it is recommended to have between 50-60 characters per line, including spaces. See Emil Ruder's "Typography"..

            3. Tom 7 Silver badge

              80 character lines is bullshit

              it needs to be 30 or less so you can code on phones.

            4. JustNiz

              80 is far too small. I normally stop around 120 and it looks fine

            5. J.G.Harston Silver badge

              Today's massive monitors mean that you're dragging your eyes across acres of screen real estate miles away from the rest of the concepts related to the bit of concept your eyes happen to be pointing to, and you forget the rest of the context because it's so far away. Why do you the the established convention in newsprint for centuries and centuries is columns that you can read by scanning downwards with the whole column width under your eyeball?

      5. Anonymous Coward
        Anonymous Coward

        reformat, compile, and write three test cases first

        First of all * has lower precedence than -> so it will mercifully not even compile without parentheses around the second *s.

        There are three routes to exit_init. Instead of reserving all the goto statements for failure cases and only dropping through for success, confusion is assured by executing the second goto when both allocations succeed, but disguising it as another failure case by returning whatever errno happens to contain. In the drop-through case it has failed to allocate, but returns zero suggesting success rather than an actual error number.

        There is no test coverage for any of the three routes. Nevertheless, it does appear either to allocate correctly, or fail without leaking. Until one day someone will notice an unexpected return value, decide to go ahead and fix it without writing and running any tests, add a supposedly missing exclamation mark to the second test, and thereby manage to break two out of the three previously working exit cases, including the all important success case.

        [Anonymous to save me having to turn down a flood of job offers to work with such fine C code, or in case my analysis is not quite correct.]

        1. Brangdon

          Re: reformat, compile, and write three test cases first

          AC, your analysis looks right to me. It took me three readings to see past that assignment of errno to ret.

      6. russsh

        Re: Maybe not goto's fault, but...

        If the second malloc fails, it will return 0 even though *s == NULL.

        I don't see how this example could be scaled to multiple substructures in a consistent idiom, either.

        1. Jeremy Allison

          Re: Maybe not goto's fault, but...

          Use talloc:

          talloc.samba.org

          It takes care of all this for you.. Seriously, it's very nice for C code. Makes something as complex as Samba even possible.

      7. AndrewInIreland

        int init_structure(struct my_structure** s)

        {

        int ret = 0;

        if((*s = malloc(sizeof(struct my_structure)))!=NULL)

        if((*s->substructure = malloc(sizeof(struct another_structure)))!=NULL)

        return 0;

        ret = errno;

        if(*s)

        free(*s);

        *s = NULL;

        return ret

        }

        1. Def Silver badge

          @AndrewInIreland

          Assignments within conditional expressions. (Extremely sloppy practice.)

          Missing braces. (All decent coding standards force you to use braces even for one liners. This is something which is very likely to trip someone up at some point in the future.)

          Testing *s before calling free. (Free(NULL) is perfectly valid.)

          Wasting time and space with redundant local variables. (Just return errno at the end.)

          Don't call us. ;)

          1. Anonymous Coward
            Anonymous Coward

            Re: @AndrewInIreland

            Style is a matter of taste. You may find the assignments "extremely sloppy", but to many others they are a familiar idiom that does actually serve a purpose.

            I am quite happy to provide you with the braces you crave, so long as you always give me a space after if/while/for, and never before a function call.

            I have seen (and removed) so many NULL checks before free (or delete) that it no longer surprises me. I like to think that those developers who were not sure used the brain cells to remember something more useful instead.

            We know that the local variable ret is just a relic of a previous revision. By all means refactor it away if it bothers you enough to risk changing working code and taking the time to retest it.

            1. Mike 16 Silver badge

              Re: @AndrewInIreland

              (this was written in reply to Anonymous Coward, but the Reg Reply seems to have misplaced it)

              Generally agree, but please add "return is not a function".

              That said, I suspect that you never ran across a system where free(NULL) did bizarre and hateful things. Programmers who have used such things get gun-shy. Much of the code I have written ran on a fairly wide variety of (allegedly) POSIX. systems, but I learned pretty early not to assume that every implementation was flawless. I wrote a simple "acceptance test" for the functions declared in string.h and ran it against the most common systems at the time (Vax VMS and BSD, DOS, SunOS). Not one passed. Don't even get me started on SunOS sprintf() and toupper().

              There's a Chesterton's Fence argument sleeping here, but I will not fully awaken it.

              As for braces, I agree in principle, but we are discussing Linux kernel code, where braces on single-statement if clauses are forbidden. Yeah, even though using them in the "goto fail" code recently under discussion would have allowed the compiler to catch it.

              And I've written FORTRAN on 90-column cards, for a compiler that IIRC Don Knuth worked on as a student. He also co-wrote a paper regarding "Notes on avoiding goto" that remains about the most sane discussion of the topic. (It also got him a witty comment from Eiichi Goto)

              1. Anonymous Coward
                Anonymous Coward

                Re: @AndrewInIreland

                I wrote C code for VAX, DOS and SunOS too, but without becoming gun shy. Then I learnt to use free(NULL), isupper, toupper, and sprintf exactly as specified in C89. These days we add platform-specific conditional compiling for snprintf and format specifier macros to cope with size_t, long long, and integers with particular numbers of bits.

              2. Michael Wojcik Silver badge

                Re: @AndrewInIreland

                I suspect that you never ran across a system where free(NULL) did bizarre and hateful things

                Since 1989, conforming C implementations have been required to handle free(NULL) correctly. Anyone writing C could should know whether the implementation they're using is actually C - that is, something that conforms to some version of ISO 9899 - or some other language which is either an ancient historical artifact or misnamed. And they should write their code accordingly, not with a bunch of cargo-cult constructs learned in other environments.

                And yes, I wrote code for pre-standard implementations; I started writing C in '87, and it took several years for conforming implementations to become common. I've tracked down and documented bugs in a few implementations. I know of common ones that still can't get it right (hello, Microsoft!). But I write code for the language and adjust as necessary for the implementation.

              3. Anonymous Coward
                Anonymous Coward

                Re: @AndrewInIreland

                " I suspect that you never ran across a system where free(NULL) did bizarre and hateful things. "

                Back in 1970 we were supporting a relatively new O/S. Every so often we would arrive in the morning to find a large pile of overnight system dumps waiting for us to analyse. We soon learned to ask the question "Who has just employed a new programmer?".

                The existing programmers had all established their own styles - and we had fixed the bugs they exposed. A new programmer found other holes - usually in error checking or other assumptions.

                One classic case was in doing double buffered I/O. It was found that the O/S call didn't expect the application to change the parameters in its control block while the operation was in progress. The fix was for the call to copy the parameters into protected O/S store.

                Comprehensive parameter checking is often neglected in implementations of functions - of which Free(NULL) is a classic example that can cause havoc.

                1. Anonymous Coward
                  Anonymous Coward

                  Re: @AndrewInIreland

                  >Comprehensive parameter checking is often neglected in implementations of functions -

                  >of which Free(NULL) is a classic example that can cause havoc.

                  Case in point; The SDK for a microcontroller platform by a big name silicon vendor corrupts the heap if you call free() with a null pointer. This SDK was released a few months ago.

            2. Def Silver badge

              Re: @AndrewInIreland

              You may find the assignments "extremely sloppy", but to many others they are a familiar idiom that does actually serve a purpose.

              Purposes like this, you mean? ;)

              http://lkml.iu.edu/hypermail/linux/kernel/0311.0/0635.html

              And yes, style is a matter of taste. However, code readability, consistency, ease of editability (with the least potential to screw up), security, and integrity trump all personal preferences when you work on a team. The coding standard is king here, and for good reason. A good coding standard dictates not only how you structure your code, but also how you use the language - or more usually which bits you shouldn't use.

              Not forcing the use of braces makes it very easy to accidentally screw up when editing code later. I've done it myself in the past. This goes doubly so for C (and to a lesser extent C++) where multi-line macros can add their own special form of mischief and mayhem.

              1. Anonymous Coward
                Anonymous Coward

                Re: @AndrewInIreland

                Not everyone has exactly the same notion of readability, or even cares that much about consistency. It doesn't always automatically slash the odds of screwing up. It might not actually be that important to trump or overrule any individual's taste to ensure that the whole team writes code that we can all read and understand and modify easily enough. Most of us are comfortable enough working with code that follows any of the more mainstream coding styles.

                I wonder if applying a const-correctness guideline to current would have been enough to stop the backdoor from compiling.

                The do { ... } while (0) idiom works wonders against multi-line macro mischief and mayhem. I'm not actually against braces, but I really can't remember the last time I saw a defect caused by omitting them. It's hard to go wrong if you write straightforward code using an editor that tracks indentation correctly.

          2. Brewster's Angle Grinder Silver badge

            Re: @AndrewInIreland

            "Wasting time and space with redundant local variables. (Just return errno at the end.)"

            From here:

            "The setting of errno after a successful call to a function is unspecified unless the description of that function specifies that errno shall not be modified." However, free() does not mention its interaction with errno...

            i.e. a POSIX compliant free() could potentially corrupt errno. (I've known implementations that will reset it to zero.)

            1. Def Silver badge

              Re: @AndrewInIreland

              That's a fair point, Brewster. I'll accept that I hadn't considered that. :)

        2. Anonymous Coward
          Anonymous Coward

          reformat, compile, and apply the style guide

          This has no less than three compilation errors: a missing semicolon, and missing parentheses around both *s before ->.

          Once those are corrected, the logic seems clear enough, and capable of passing tests. So we can move on to look at style, performance, and portability.

          Using a local variable (register) to hold an output result is a common tip to make code smaller and faster and a little clearer. The register needs copying to the output parameter *s just before each return.

          Most style guides mention that there is no need to check for NULL before calling free. The check is here either because a developer did not know that for sure, or perhaps just so that others who might read the code do not need to know that for sure. We can probably rule out an attempt to tune the failure case by saving a function call at the expense of an extra test in the success case.

          It is hard to contrive a situation where it would be useful in practice, but some C dialects do permit empty structs, for which a malloc implementation can return either a pointer to nothing, or NULL. That will cause the success case to fail.

        3. Michael Wojcik Silver badge

          if(*s) free(*s);

          The test is unnecessary. C (ISO 9899) has always required free() to do nothing if the argument is a null pointer. Yes, you have the overhead of a (leaf) function call, but that's a negligible price to make the source more straightforward and readable, and remove a possible source of error (like, say, someone not noticing the if-body isn't a compound statement, and trying to do something else inside it without correcting that).

    2. stanimir

      >> GOTO is still cool.

      ...And it has always been in the Linux kernel.

    3. -tim
      Boffin

      goto might disappear

      Gotos will only become fully obsolete when CPUs no longer require their version typically known as a branch or jump instruction.

      1. Lars Silver badge
        Happy

        Re: goto might disappear

        If you know machine/processor code there is always, and has always been, a goto, Then you can play around with the "return" (again a goto) to produce a subrutine or what ever you want to call it. The goto will never disappear. What has mixed you up, nothing "wrong" with that, is the sentence "Goto considered harmful" or you are taking about some makro language like Algol, a nice language, I used 40 years ago, perhaps there was a goto there too. Then again, why the hell, did I goto into this.

    4. JulieM Silver badge

      GOTO Hell

      A good programmer can write a program without a single GOTO.

      A true hacker can save many lines of code, and not adversely affect program readability, with just one well-placed GOTO.

  4. boltar Silver badge

    God help linux...

    If the contributers to the kernel start behaving like those foolish little children calling themselves students in the USA who seem to believe that any opinion they find offensive somehow infringes their human rights and require "safe spaces" so they don't have to confront them, then the project is doomed. Linus might be an ass sometimes but he's the boss and if you don't like the way he operates or can't handle being treated like a functioning sentient adult rather than a baby who needs to be coo-coo'd to, then go play elsewhere.

    1. Craigness

      Re: God help linux...

      There will be people checking to see if the work was done by someone from a protected class so they can ask Linus to resign for offences against social justice. All POC pull requests must be accepted.

      https://archive.is/kLKc0

    2. Turtle

      @boltar Re: God help linux...

      "Linus might be an ass sometimes but he's the boss and if you don't like the way he operates or can't handle being treated like a functioning sentient adult rather than a baby who needs to be coo-coo'd to, then go play elsewhere."

      There are plenty of bosses who would love to have an obsequious toady like you in their employ. Your idea of an ideal leader would be Stalin, right? Perhaps you'd feel more at home in North Korea, eh?

      It is actually Torvalds who is acting like a child; that an (ostensible) adult would have these kind of tantrums is astonishing. And he can get away with acting like this because he is constantly pampered: see for example the very first post in this thread, where another lickspittle-in-waiting (one "Rol") wrote that this kind of self-indulgent tantrum signifies that "he still cares enough about his baby to kick ass when needed." One has to be quite emotionally / psychologically crippled to confuse these kinds of verbal attacks with "caring".

      He has poor leadership skills, and shows an inability to control himself. And people who can not control themselves should not be in control of other people.

      I recall reading something that lamented the fact that it was Torvalds and not Alan Cox who ran Linux. But then again, Cox left Linux for a long time because of Torvalds. How conducive to Linux's progress was that, do you think?

      1. Anonymous Coward
        Anonymous Coward

        Re: @boltar God help linux...

        @ Turtle

        I used to work for a major international chemical company as part of a root cause team. When investigating why we were getting out of specification failures, it was discovered some idiot had not checked calculations as they were supposed to through sheer laziness. That little boob cost the company £10M straight off the bottom line but luckily didn't explode the plant. It's a grown up world out there where lazy actions can cost lots of money and potentially lives so a verbal arse kicking to slackers is quite justified.

      2. boltar Silver badge

        Re: @boltar God help linux...

        "There are plenty of bosses who would love to have an obsequious toady like you in their employ. "

        AFAIK Linus doesn't employ anyone and the kernel isn't a company project (ok, you can debate what Dead Rat and Canonical get up to but thats another argument...). You take part of your own free will under no duress knowing exactly what things will be like if you fuck up in a major way. Don't like it? Don't do it.

        "He has poor leadership skills, and shows an inability to control himself. And people who can not control themselves should not be in control of other people."

        Yet oddly he's kept this project on track since 1991. Lets see you manage that. No doubt your approach would be something like: "Oh, this code didn't quite work, shall we take it offline for a 360 where we can have a heads up and drill down into your performance metrics and facilitate a new mindshare knowledge transfer from the other team stakeholders?" Blah fucking blah.

        "But then again, Cox left Linux for a long time because of Torvalds."

        Did he? This is a direct quote from his Google+ page:

        ---------------------------------------------

        I'm leaving the Linux world and Intel for a bit for family reasons. I'm aware that "family reasons" is usually management speak for "I think the boss is an asshole" but I'd like to assure everyone that while I frequently think Linus is an asshole (and therefore very good as kernel dictator) I am departing quite genuinely for family reasons and not because I've fallen out with Linus or Intel or anyone else. Far from it I've had great fun working there.

        ---------------------------------------------

        I see absolutely no reason for him to dissemble this time given he's been quite open in the past about disputes. Perhaps you should check your facts before clicking on reply.

      3. naive

        Re: @boltar God help linux...

        Actually, God helped Linux by giving it Linus as creator.

        What all the ".. he is acting like a child types .." do not get is that Linus is the man blowing the whistle in the WW1 trench, knowing that the actions of each individual not only affect the result of the operation, but also the fate of all others. Developing kernel code is as much a moment of truth, as leaving the trench, requiring decisive leaders not allowing weakness or mistakes.

        Leaving one such line, would soon turn the whole kernel code base into a pile of junk, since with each new release more of such mistakes would sneak in without the oversight of men like Linux Torvalds.

  5. Platypus

    Let's not overgeneralize. *This time* he didn't name names. On the other hand, he still did make some pretty strong inferences about "whoever" wrote the code, and "whoever" isn't hard to discover. That's well beyond just criticizing the code.

    On the other other hand, I've been on too many projects that *didn't* lay down the law this firmly. Developers are a sneaky lot, and they tend to have their own agendas. They'll keep sneaking in code that they know is crap, if it lets them mark more of their personal tasks complete. If nobody is watching, or nobody responds strongly enough to put the fear of God into them, the result is a codebase that slowly rots into irrelevance. I do think Linus and (even more so) certain other Linux kernel developers behave in some pretty toxic ways sometimes, but as we try to improve that situation we still need to remember that bringing the hammer down once in a while is strictly necessary to maintain any kind of quality. It's all in how it's done, not whether it should be done at all.

    1. Charlie Clark Silver badge

      This make me ask: why does the person who committed the code still have commit rights?

      Maybe it's debatable as to how possible compiler optimisations are reflected in source code. I've always thought it was the compiler's job to figure this out using minimal sugar in the source. But this kind of debate is obviously misplaced in the kernel and probably indicative of other issues: maybe it's time to part ways.

      1. Alan Brown Silver badge

        "why does the person who committed the code still have commit rights?"

        What makes you think he still does?

      2. Tom 38 Silver badge

        This make me ask: why does the person who committed the code still have commit rights?

        No-one has "commit rights" anymore, this is the purpose of git. Linux sees pull requests, and he can see pull requests from anyone.

        Regardless, whoever this was should still have their metaphorical "commit bit". Just don't present code like that again - plus, Linus use of invective about the crap quality has ensured that this is widely discussed, and the reasons why Linus doesn't like that code disseminated, and he doesn't have to tell any other junior neophytes from the cult of GCC not to do similar in future.

    2. Alan Brown Silver badge

      "Developers are a sneaky lot, and they tend to have their own agendas. They'll keep sneaking in code that they know is crap, if it lets them mark more of their personal tasks complete."

      This is happening more and more often in the Linux kernel. The Microsoft Mentality ("Ship it now, fix it later") is still widespread and many coders have migrated over to Linux (and BSD) without shaking it off.

      The vast majority of this kind of crap shows up in hardware drivers (generally written by coders working to manglement deadlines) and without Linus policing it the kernel would rapidly become unusable.

      Some argue that drivers should be external to the kernel, but that would make things even worse. The binary blobs we have to put up with at the moment are bad enough.

      Just be glad that the "Paid by production" subcontractor model(*)(**) doesn't get past Linus either.

      (*) "Never write a 3 line function when you can write 6 pages of incomprehensible code instead."

      (**) There are a lot of coders who will do this even if not incentivised by the modern equivalent of "a penny per word", thanks to way they were taught.

      1. Charlie Clark Silver badge
        Thumb Down

        There are a lot of coders who will do this even if not incentivised by the

        Downvoted for "incentivised"! ;-)

        Though I'm not sure the charge applies to the open source development. I think buzzwords and fads are more likely explanations for convoluted and error-prone coding.

        It goes without saying that drivers should not be in kernel space. Even if this is only an organisational distinction.

        1. Alan Brown Silver badge

          "Downvoted for "incentivised"! ;-)

          Though I'm not sure the charge applies to the open source development."

          The vast majority of shitty driver code is submitted by people who are _paid_ to write driver code for devices produced by their employers.

          Usually the "non-professionals" have to pick it apart and rewrite it into something that actually works.

  6. Chris Gray 1
    Facepalm

    Ooops

    Sorry, Stuart, you got the error handling wrong - you want it to return 0 if the substructure alloc worked. If it didn't, you want to free 's' and then return 'errno'.

    In situations like this, 'return' is your friend. On the Amiga, the OS doesn't track your allocations, so in any error situations, you have to free allocated stuff yourself. The structure I tended to use was a big 'if' sequence, testing for success. Somewhere in the middle, everything is setup properly, and I 'return' from there. After the various levels of 'if' comes undo code for stuff successfully setup before that 'if'. Worked pretty good. I did cheat in one case and change the indentation to 2 instead of my default 4, though. The alternative is to just call an interior init function that is structured the same way.

    1. Anonymous Coward
      Anonymous Coward

      Re: Ooops

      Heh, morning cup of tea hasn't taken effect yet. See this is why I don't start coding the moment I get to my desk of a morning.

  7. Khaptain Silver badge

    It's the Viking thing

    I love Linus' no-nonsense way of thinking.

    I presume that the Sarah Sharp sympathisers will be once again up in arms over this latest episode..

    Personally I prefer a boss that lets you know where you stand instead of the namby pamby approach where nothing gets resolved and just lingers on and on creating nothing more than frustration for all involved...

    Anyone with excellent vocabulary skills can be twice as damaging as someone who just uses "profanity.." Actual swear words have no importance, what is important is the reasoning behind them.

    1. Trixr Bronze badge

      Re: It's the Viking thing

      Why would the "Sarah Sharp sympathisers" (it ain't just Sarah Sharp, come on) be "up in arms" about this.

      For once, Linus isn't being personally abusive. Very few people care about the actual swearing - no-one likes being sworn AT. If someone tells me what I've done is f***king stupid, I get the message, actually. Telling me that I'm f***king stupid makes me instantly think "f**k off, I'm not, I made a mistake" and not exactly keen to bother with their "critique" in future. I think it's a marked improvement, frankly.

      1. Craigness

        Re: It's the Viking thing

        "For once"

        Really, just one time? Do you realise that another time was the Sarah Sharp incident, where she made a personal attack, swore at him and in return he offered cookies?

      2. Khaptain Silver badge

        Re: It's the Viking thing

        "Why would the "Sarah Sharp sympathisers" (it ain't just Sarah Sharp, come on) be "up in arms" about this."

        Because they like to take this at face value, do not care about the rest of the details.

        Personally I do not believe that a softly, softly approach is a good solution when faced with difficult situations. Linus takes his job seriously and expects those around him to be the same, this is a well known fact "before" you take on the job....If you don't want to be in that situaiton then you don't take on the job. Up until now I would say that Linus has done far better than anyone else that I can imagine regardless of his attitude or usage of big bad swear words....

        A softly softly approach would more than likely lead to disastrous results as that shitty code would have eventually been accepted in order to keep the peace...

  8. silent_count

    The last block of code in the article is missing a ")" before the "goto".

    That aside, Mr Torvalds is right in this specific case, and in general too. A lot of the constucts used to work with, and around, the preprocessor are just ugly and could quite happily be dragged out behind the back of the shed and shot.

  9. Anonymous Coward
    Anonymous Coward

    his rant...

    ...is just as pathetic as the code. linus grow up and stop acting like such a man child.

    1. Anonymous Coward
      Anonymous Coward

      Re: his rant...

      Indeed. In any professional organisation he'd have been fired for bullying but the F/OSS lot love him for some reason. Is it any wonder people are quitting Linux in disgust at his behaviour?

      1. Doctor Syntax Silver badge

        Re: his rant...

        "In any professional organisation he'd have been fired for bullying"

        I take it that by "professional organisation" you mean a company. In any company the coders would have annual - or even more frequent - reviews. There would be more formal disciplinary approaches. People not meeting standards would eventually cease to be paid.

        The Linux kernel team isn't a company. Some contributors may be being paid by various companies to take part but even so, unlike a manager in a company, Linus has no influence on this. The only influence he has is to accept or refuse code according to his standards* and to make clear why code is being refused. With so many contributions coming in he can't simply afford to be deluged with sub-standard code and with such a large and loosely aggregated population of contributors and would-be contributors he needs to get the message out loud and clear.

        So how, given the realities of the situation, would you deal with substandard code?

        *I have to say I don't agree with all his decisions, lack of raw devices being one.

      2. fajensen Silver badge

        Re: his rant...

        In any professional organisation he'd have been fired for bullying ... which is possibly why we find ourselves building a "digital economy" solidly founded on a growing pile of rotting garbage dragged up as reliable, secure, responsive .... products and services?

      3. Evil Graham

        Re: his rant...

        In any professional organisation he'd have been fired for bullying

        It's only bullying if he picks on specific individuals. All the evidence I have seen suggests that Linus just cares about the quality of the code, no matter who it comes from.

        I've worked in hardware and software development for more than 30 years and I have never been anywhere where this would be taboo, provided the criticism was justified and that it was directed against the work rather than the person.

        I think if your corporate culture is hyper-protective to the point where any kind of conflict is suppressed or avoided, then your precious employees are going to have a shock when they interface with the real world.

  10. Jim 43

    In other news

    I sent a nasty email to the cow-orker who used cat before grep

    1. JulieM Silver badge

      Re: In other news

      What about the ones who pipe grep (to find something) through grep -v (to get rid of the stuff it found but you don't want) and then through awk (to grab just the interesting bits)?

  11. Number6

    Can't fault him this time

    Sometimes I think he's overreacting, but looking at those code examples, I agree with him 100% on this issue.

    1. Alan Brown Silver badge

      Re: Can't fault him this time

      Linus is as effusive with his praise as his brickbats, but that doesn't make for good clickbait.

  12. Version 1.0 Silver badge

    Coincidence?

    I just read "Although, some people can program in an assembly language and understand the intricacy of the spacecraft, most younger people can't or really don't want to," in the accompanying story on the lack of FORTRAN programmers ... these are symptoms of the same problem - many programmers are a lazy bunch who generally just get by - check the box, mark it as accomplished and move onto the next project.

    I had one guy once who actually believed that if it complied without any errors then if had to be good code - I fired his ass, criticism can only do so much.

    1. gerdesj Silver badge

      Re: Coincidence?

      I thought that "complied without any errors" was a prerequisite for a build to finish. Warnings on the other hand ...

      1. Anonymous Coward
        Anonymous Coward

        Re: Coincidence?

        'Compiled without errors' only means you defeated the compiler. The next round is against the system, who will lay the smackdown on your newb code with his dreaded SIGSEGV attack. Train hard... after you defeat the system, you're up against The BlackHat. If you're lucky, you can survive the BlackHat match and go on to face The Changed Requirements

    2. Destroy All Monsters Silver badge
      Flame

      The FORTRAN FEMA trailer has stopped nearby....

      > lack of FORTRAN programmers

      I hope the genocide continues and spills over into the "C" language crowd.

      1. Dazed and Confused Silver badge

        Re: The FORTRAN FEMA trailer has stopped nearby....

        C, FORTRAN, pahhhh who cares, a good FORTRAN programmer can write FORTRAN in any language.

        1. Warm Braw Silver badge

          Re: The FORTRAN FEMA trailer has stopped nearby....

          >a good FORTRAN programmer can write FORTRAN in any language

          I once had the misfortune to work with FORTRAN code developed by a bunch of naval architects. Most of the variables were women's names. Or girls' names, as they would have put it. Not a trait that was language-dependent.

        2. Doctor Syntax Silver badge
          Happy

          Re: The FORTRAN FEMA trailer has stopped nearby....

          "a good FORTRAN programmer can write FORTRAN in any language."

          Following our FORTRAN course (one week of which I missed the first day) I discovered from a colleague that it was possible to write bad BASIC in FORTRAN.

        3. Carlie J. Coats, Jr.

          Re: The FORTRAN FEMA trailer has stopped nearby....

          And a good lisp programmer can write lisp in any language -- including Fortran. :-)

      2. Alan Brown Silver badge

        Re: The FORTRAN FEMA trailer has stopped nearby....

        > I hope the genocide continues

        You just wiped out most of the astrophysics community.

        Other than the ones who use IDL as a general purpose programming language.

        1. Destroy All Monsters Silver badge
          Trollface

          Re: The FORTRAN FEMA trailer has stopped nearby....

          > You just wiped out most of the astrophysics community.

          Yeah, I have seen those kind of "writing" by a PhD student.

          1) Borrow olden code in FORTRAN to do fluid dynamics around a blackhole

          2) Not sure what it does, how to call it but it fits right in where I have these call parameter things. Also runs well on the basement vector processor (remember this was a bit earlier in my career)

          3) Produces pretty graphs which look good on the projector. "Nobody else will use it anyway"

          4) ???

          5) SORTED!!

          Next grad student will pick up the code at 4)

          1. Carlie J. Coats, Jr.

            Re: The FORTRAN FEMA trailer has stopped nearby....

            You should see Ph.d.-candidate C++. It's much worse.

            Or Java written by someone who belives "structure is good. The more structure the better, no matter whether it is relevant or not to the situation at hand." I've seen so-called scientific visualization stuff with more *files* than there are lines of code in my C package.

  13. John H Woods Silver badge

    Wrong Jar?

    Given the reception usually afforded to Linu{x|s} articles here, I was wondering if you'd chosen the wrong jar for the hero graphic (although I wish you'd drop these) -- maybe you meant this. I think it'd make a good icon ...

    1. allthecoolshortnamesweretaken Silver badge

      Re: Wrong Jar?

      One should never argue about taste - but please, please keep that stuff away from me...

  14. TeeCee Gold badge
    Mushroom

    Ohshit.

    The webbie crowd have decided to get into kernel development.

    This is the same problem that every fucking web monkey I've ever had the displeasure of dealing with has. Given "way everybody does it that we all know works and is bulletproof" vs. "NEW11!!!!1111 way of doing it that'll look rilly kewl on my CV",guess which one they go for? Every. Fucking. Time. Without. Fail.

    1. Destroy All Monsters Silver badge

      Re: Ohshit.

      Go back to your PHP.

  15. Blank Reg

    I started my programming career in telecom where your code had to work 24x7x365, no excuses. And so my code is what I refer to as "kindergarten code". It's always as simple as possible, even if it takes a few more lines to accomplish. It should always be easy to understand with no fancy tricks, no showing off allowed, no cramming 20 lines worth of code in to one convoluted undecipherable mess of a line.

    Someday, someone else is going to have to look at your code, so don't be an asshole, make sure they have a fighting chance of understanding what you've written and why.

    1. Captain DaFt

      "Someday, someone else is going to have to look at your code, so don't be an asshole, make sure they have a fighting chance of understanding what you've written and why."

      And if you don't, the day will come when you're trying to understand some piece of code and shout, "Who the Hell wrote this crap!?", then realize it's your old code.

      1. Doctor Syntax Silver badge

        " it's your old code."

        And 6 months easily qualifies as old.

    2. Alan Brown Silver badge

      "I started my programming career in telecom where your code had to work 24x7x365, no excuses. "

      One of my cousins was working in telecom in the late 70s/ early 80s on FACOM mainframes.

      He spent nearly his entire time having to pull a Linus on coders who thought it was acceptable to write pages of incomprehensible (and fragile) gibberish instead of simple elegant functions. The problem is that he inevitably had find it _after_ it had been deployed and was causing problems in the billing systems.

      Such coders are at the core of many of the PR problems you see at various major utilities and they're also found writing stuff which is critical to safety-of-life functions.

    3. hiiq

      27 x 7 x 52 or 24 x 365

      Choose one

      1. PBNV

        I choose neither: I prefer to think he needed to be sure that his code would run for (almost) seven years.

        1. maffski

          I prefer to think he just added a fudge factor to cover leap years. A simple and elegant solution.

      2. Vic

        27 x 7 x 52

        They're going to refuse your overtime claims...

        Vic.

    4. This post has been deleted by its author

    5. Evil Graham

      And so my code is what I refer to as "kindergarten code".

      I gave you an upvote, but what I really wanted was to give you a job.

  16. david 12 Bronze badge

    It's not that simple.

    The C language definition people have codified rules to make C as fast as FORTRAN and Pascal, but without VAR declarations and strict type checking.. And the C compiler people have implemented the standardised shortcuts to make C as fast as FORTRAN and Pascal.

    You can't make assumptions like "a+1 > a" or

    hlen + sizeof(struct frag_hdr) < hlen + sizeof(struct frag_hdr) + 8

    Hence the "magical built-in compiler support", for magical built-ins like overflow_usub.

    Now I'm not commenting on the specific code: probably there is other information that means the expression is safe in that line, using those veriables, at that point. But thst's the way of madness, and how unreliable code gets written.

    And personally, I think it would be a bit unfair to blaime the coders for writing obscure compiler-specific code, when the language specification and compiler writers have devised a language where it is not safe to write clear simple code.

    There is a small amount of push back: one suggestion is that it would be nice if C compiler developers could offer the option to turn off "unsafe optimisations", based on some simple studies of where their C compiler break expectations. Obviously, this would come up against the old C/unix expectation that it's the users responsibility to be excelent and avoid bugs, not the computers (and that anybody who needs help to avoid language warts is a looser anyway), so I've not seen that's it got much support.

    1. Fibbles

      Re: It's not that simple.

      You can't make assumptions like "a+1 > a"

      Forgive my noobishness then, but why can't you make that assumption?

      The only thing that comes to mind is the value overflowing.

      1. sed gawk

        Re: It's not that simple.

        Your are correct it's about proper checking for integer over/underflow.

        For unsigned variables you have to check the carry flag to see if under/overflow has occured.

        if( (foo - 1) > foo){

        // underflow foo has wrapped to high range

        }

        if( (foo + 1) < foo){

        // overflow, foo has wrapped to zero

        }

  17. Destroy All Monsters Silver badge
    Paris Hilton

    There is code smell in here

    mtu -= hlen + sizeof(struct frag_hdr);

    1) Use of the error-prone "-=" only liked by crazed C-fashionistas

    2) sizeof(struct frag_hdr) should prolly be constant, why is it computed here?

    But most important:

    Feels like "mtu" should be constant in this context. That's what "mtu" means. We are modifying it?

    1. Phil O'Sophical Silver badge

      Re: There is code smell in here

      2) sizeof(struct frag_hdr) should prolly be constant, why is it computed here?

      It's not, sizeof is processed at compile-time. That expression is a constant.

      Feels like "mtu" should be constant in this context. That's what "mtu" means. We are modifying it?

      We aren't, we're determining it. MTU is customarily negotiated between the ends of the connection.

    2. Kanhef

      Re: There is code smell in here

      2) The size of a struct can be determined at compile time, no need to store it in a variable. Hardcoding the value isn't a good idea, as it reduces platform independence, maintainability, and readability.

      3) I'm not familiar with the code in question, but 'mtu' is probably a local variable, initially set to the MTU size and decremented as a packet is processed. You could use a 'packet_size' variable instead, but then you'd have to look up the MTU size every time you check for overflow, whereas this way you just check if 'mtu' is negative or not.

      1. Doctor Syntax Silver badge

        Re: There is code smell in here

        "Hardcoding the value isn't a good idea, as it reduces platform independence, maintainability, and readability."

        And in case anyone missed the maintainability aspect it makes the code particularly vulnerable to any change in the struct.

        1. Indolent Wretch

          Re: There is code smell in here

          Self documenting code is an excellent goal in any C project.

        2. ST Silver badge
          Mushroom

          Re: There is code smell in here

          it makes the code particularly vulnerable to any change in the struct

          Go back to writing Visual Basic for Excel Applications. C isn't your thing.

      2. dajames Silver badge

        Re: There is code smell in here

        3) I'm not familiar with the code in question, but 'mtu' is probably a local variable, initially set to the MTU size and decremented as a packet is processed. You could use a 'packet_size' variable instead, but then you'd have to look up the MTU size every time you check for overflow, whereas this way you just check if 'mtu' is negative or not.

        Part of the point of this discussion is that mtu is an unsigned integer, so it doesn't become negative after an underflow. It does assume a stupidly large value after underflow and one could check for that, but such a check would be (marginally) more complicated and would result in (considerably) less readable code.

    3. Anonymous Coward
      Anonymous Coward

      Re: There is code smell in here

      >2) sizeof(struct frag_hdr) should prolly be constant, why is it computed here?

      Way to prove you have no idea what you're yapping about. Any chance of you not commenting on articles/comments about C with your usual drivel now?

      1. Destroy All Monsters Silver badge
        Pint

        Re: There is code smell in here

        > Way to prove you have no idea what you're yapping about. Any chance of you not commenting on articles/comments about C with your usual drivel now?

        Says an anonymous coward who is quite likely wetter behind the ear than a baby wipe. GB2 XBox, jerk.

        Also, who has talked about "hardcoding"?

        1. James Hughes 1

          Re: There is code smell in here

          I'm not anon, and was also surprised on the comment about sizeof, which has always been calculated at compile time as a constant, and I would expect even a slightly experienced C programmer to know that.

        2. desht

          Re: There is code smell in here

          He might be anonymous, but he's right. If you don't know that sizeof is a compile-time calculation, you have no business commenting on the quality of C code.

    4. GrumpenKraut Silver badge

      Re: There is code smell in here

      "-=" avoids duplication, as in " a -= 3" versus "a = a - 3". Beholder an all that, but if you get your knickers in a twist about this you may want to stick to BASIC.

  18. Donkey Molestor X

    wow, we got all the balls in the world in this thread.

    you guys all talk a big game about how you would go "yes, linus, may i please have another?".

    if he were actually your boss you would either complain or you would just walk off the job.

    what are any of you actually complaining about? moving bounds checking and overflow checking to the compiler using special functions? if your difficulty with that is that it is not in the C spirit of things i'll certainly cop to that. the C way of doing things is to never bounds check and leak resources everywhere and let your stack get smashed because "real" programmers certainly never check their math more than once.

    this is why you are all being replaced by Indians who do the work for 1/10th the salary and 0/10ths of the ego.

    1. Richard 12 Silver badge

      The Linux kernel is the most compiled thing anywhere

      It has to be 100% compatible with every single C compiler on the planet, because they're all going to compile it.

      It is not a place where you should - or even can - use funky compiler features.

      It matters if it doesn't compile using the esoteric C compiler developed for a specific rare CPU, or causes unexpected side effects due to rare compiler bugs - or difference in interpretation of the C standards.

      The Linux kernel is probably the only large library that is used on every CPU currently manufactured - as well as many that aren't.

      1. Anonymous Coward
        Anonymous Coward

        Re: The Linux kernel is the most compiled thing anywhere

        >It has to be 100% compatible with every single C compiler on the planet,

        >because they're all going to compile it.

        Linux only really compiles with GCC, maybe clang (not sure what the state of that is) and maybe some stuff like the Intel compiler. It does not compile with every compiler on the planet by a long way.

        >It is not a place where you should - or even can - use funky compiler features.

        Except that the Linux source tree has support for doing just that. I.e. having macros etc to fill in features that aren't supported on certain compilers/GCC version/platforms..

        >It matters if it doesn't compile using the esoteric C compiler developed for a specific rare CPU,

        > or causes unexpected side effects due to rare compiler bugs - or difference in interpretation

        >of the C standards.

        Linux doesn't compile on any esoteric compiler. You're talking out of your bottom.

        >The Linux kernel is probably the only large library that is used on every CPU

        >currently manufactured - as well as many that aren't.

        There are CPUs manufactured today that don't have C compilers.. so how does that even work?

      2. Destroy All Monsters Silver badge

        Re: The Linux kernel is the most compiled thing anywhere

        "It has to be 100% compatible with every single C compiler on the planet, because they're all going to compile it."

        Just what.

        Oh wait. Sarcasm.

      3. ST Silver badge
        Flame

        Re: The Linux kernel is the most compiled thing anywhere

        It has to be 100% compatible with every single C compiler on the planet, because they're all going to compile it.

        No, it doesn't. Only GCC and maybe the Intel Compiler can compile the Linux Kernel. I'm not even 100% certain about the Intel Compiler.

        Clang can't compile the Linux kernel, MSVC can't and PGI can't either.

        Here's a bit of advice: if you have never, ever, tried compiling the Linux kernel from source, don't post self-aggrandizing bullshit pretending that you have. You'll get caught and called on it by those of us who do this on a regular basis.

        Also, the Linux Kernel is not a library. It's a relocatable.

    2. Alan Brown Silver badge

      "this is why you are all being replaced by Indians who do the work for 1/10th the salary and 0/10ths of the ego."

      Seeing as you brought up indians: The vast majority of the offenders in the "write as much as possible to do as little as possible and see how many latent bugs you can include" camp are indian subcontractors.

      You get what you pay for and they can make up the low upfront costs in consultancy later when you find the code can't do what's needed.

    3. Doctor Syntax Silver badge

      @ Donkey Molestor X

      "this is why you are all being replaced by Indians who do the work for 1/10th the salary and 0/10ths of the ego."

      But are probably better than you at starting sentences with capital letters.

      Seriously, consider your use of the word "boss". Nobody who submits code is managed by him. Either they do so off their own bat or they're employed by other organisations where he has no managerial role. The number of individuals submitting is far, far greater than any conventional manager would have to deal with. How would you cope with the situation?

  19. Erewhon

    Stop being a dick.

    We get that you are smart and right. But you don't have to rant like a child just because you are.

    Educate and inform. If their skills or approach does not improve then remove them.

    No need to go all postal in the process.

    1. Doctor Syntax Silver badge

      Re: Stop being a dick.

      "Educate"

      How? There are thousands of contributors and many thousands of contributions. Would you have time to give individually written feedback educating them.

      " and inform."

      Well, they've just been informed, haven't they?

      "If their skills or approach does not improve then remove them."

      How? Remember he doesn't employ them. He doesn't call them into his office for annual reviews which will be sent up to HR.

      1. This post has been deleted by its author

      2. Erewhon

        Re: Stop being a dick.

        Yes educate. Put people and processes in place to give feedback on best practice and why certain coding approaches are incorrect or suboptimal. There's no need to be a dick about it.

        And if your version control mechanism doesn't allow you to block updates from persistent offenders, then there is a flaw in the process. Fix the process. There's no need to be a dick about it.

        1. Evil Graham

          Re: Stop being a dick.

          There's no need to be a dick about it.

          It's more fun if you are though.

    2. Alan Brown Silver badge

      Re: Stop being a dick.

      "No need to go all postal in the process."

      The _only_ times I've seen Linus go off at individuals is when said individuals had done more than enough to deserve it.

      He doesn't do it for a 1st (or even a 2nd or 3rd) offence. You have to be a serial submitter of poor code to get the public scorning and it's done because certain individuals are such precious little flowers that public humiliation is the only way the message sinks in.

      This isn't a company. He can't fire people. They can't even be banned from submitting. They can only be named and shamed if they're continually wasting Linus' (and others') time.

  20. sabroni Silver badge

    So no problems with magic numbers then?

    What's that "+ 8" doing there? Just added a little bit more to be on the safe side?

    1. david 12 Bronze badge

      Re: So no problems with magic numbers then?

      ?What's that "+ 8" doing there? Just added a little bit more to be on the safe side?

      It's part of the specific check, added in the new code, (probably for security to avoid unexpected over-run errors), only loosely related to the original code.

      The old code didn't check that mtu was big enough before subtracting.

      The new code checks that (a) there is no overflow when it does the subtraction, and (b) the result is still big enough (8) for whatever comes next.

      Both the new versions of the code include the "at least 8" or ">7" check, but the first version of the new code used an obscure new compiler-specific method of avoiding overflow in the check. Without seeing the rest of the code, it's not possible to say if the new Linus version works correctly, which is why the compiler writers provided the obscure new compiler-specific method.

      An option for the compiler writers would have been to provide a compiler that did work as expected without requiring a new compiler-specific method, but they didn't do so, because "it's not required by the C standard".

      I have no idea if the Linus rant was actually directed at the compiler writers for providing such a platform, rather than at the poor coder who was forced to work in that environment: it will be interesting to see if there is any defence / follow up.

      1. sabroni Silver badge

        Re: the result is still big enough (8) for whatever comes next.

        Thanks for having a go, but that's not really any clearer. What exactly is it that's coming next that is 8 big and how do we know that 8 is going to be enough? If it's leaving room for a specific thing then there should be something defining the size of that thing, surely?

        Still looks like a magic number to me, yet this is Linus' fixed version of the code. So what's going on?

  21. T. F. M. Reader Silver badge

    It is quite instructive ...

    ... to read the thread in LKML (just go to the link to Linus's post and follow from there). The person who submitted the code immediately responded (no need for detective work), the network subsystem maintainer (Dave Miller) followed, the commit was reverted, a patch without the offending compiler wrapper was re-submitted.

    It is obvious that despite the (characteristically) colorful language the criticism was understood by everyone involved to be professional and not personal, the reaction was professional as well, and the entire situation was handled intelligently and efficiently.

    I suspect Linus knows very well that the somewhat impersonal nature of email provides for additional tolerance of colorful vocabulary, and the strong language is probably both a personal trait and a tool. When he makes a technical point he does it forcefully, and this makes him more effective in the absence of personal interaction.

  22. WatAWorld

    Much better !!!

    I have to give credit where credit is due.

    Linus Torvalds is focusing on the issue, not the individual. He is not embarrassing people publicly or in front of their peers. Linus is doing his criticism the right way now.

    Hopefully this will lead to more companies being willing to have their employees work on and with Linux.

    1. davefb

      Re: Much better !!!

      Not really, its clear who the individual is, because they're in the thread which the childish rant is from.

      Following the thread, where the other coders speak like adults, it appears to have been part of code which was put in to be discussed after being looked at, but nobody bothered reviewing the changes.

      "> Get rid of it. And I don't *ever* want to see that shit again.

      No problem, I'll revert it all.

      I asked Hannes to repost his patches to linux-kernel hoping someone

      would review and say it stunk or not, give him some feedback, or

      whatever, and nobody reviewed the changes at all..."

      1. Anonymous Coward
        Anonymous Coward

        Re: Much better !!!

        > but nobody bothered reviewing the changes.

        What?! There aren't a million eyes reviewing this open source code to make it super secure? Who'd have thought it.

  23. Simon Harris Silver badge

    Visual studio.

    Often berates me for using a C standard library function, and suggests that some alternative is preferable.

    The Linux version of GCC should come with a 'Linus' mode that automatically castigates programmers for using some non-standard extension using more fruity language.

    1. Anonymous Coward
      Anonymous Coward

      Re: Visual studio

      "The Linux version of GCC should come with a 'Linus' mode that automatically castigates programmers for using some non-standard extension using more fruity language."

      -std=linus91

  24. Anonymous Coward
    Anonymous Coward

    Hey, at Microsoft you got furniture thrown at you.

  25. Anonymous Coward
    Anonymous Coward

    While I completely agree that the submitted code should be struck down and never see the light of day again the way it was done was wrong. Having a go at your staff is rarely, if ever, the way to get the best out of them. Sure Linus didn't actually name names but anyone who cared could go and look up who was being torn off a strip so this is as good as a public humiliation. I personally wouldn't contribute to a project with someone like that at the wheel and I can't believe I'm the only one that feels that way.

    1. Doctor Syntax Silver badge

      "Having a go at your staff is rarely, if ever, the way to get the best out of them."

      What staff?

      "I personally wouldn't contribute to a project with someone like that at the wheel and I can't believe I'm the only one that feels that way."

      The number of kernel contributors suggests that there are plenty who feel differently.

  26. Zork-1
    Devil

    "

    if (mtu < hlen + sizeof(struct frag_hdr) + 8)

    goto fail_toobig;

    mtu -= hlen + sizeof(struct frag_hdr);

    "

    It's still "RUBBISH" :P

    what if "hlen + sizeof(struct frag_hdr) + 8" causes an overflow and ended up <= mtu but the intended value (if given more bits to store) is actually > mtu?

    c.f. if (A < B + C) ...

    1. James Hughes 1

      Patch required

      The advantage of Linux is that you can go and fix the problem you have described, submit it, and see what happens. If the peer review is successful, well done!

    2. Carlie J. Coats, Jr.

      sizeof --> size_t

      Because "sizeof" gives a "size_t", the entirety of "hlen + sizeof(struct frag_hdr) + 8" should also be "size_t" and the comparison should be of "size_t".

      Assuming a 32-bit system, you're in trouble with networking code for which this overflows.

      And if it does, then (it's unsigned, remember), the overflow will be to a small value

      and the test will fail for that reason.

      If it's a 64-bit system and there is any danger of trouble, your network has long since gone past what it can deal with. And you're requiring far larger messages than either the OS or any conceivable hardware (for at least the next decade) can deal with.

    3. gnasher729 Silver badge

      Can't happen. hlen is taken from a sixteen bit variable. Can't possibly be bigger than 65535.

  27. tony2heads
    Trollface

    Don't hold back Linus

    Just let us know what you really feel

  28. Gideon 1

    GCC is at fault here

    for giving noobs non-standard-compiler-feature ammunition to shoot themselves with.

  29. Mr Tank

    All those hours wasted in boots or WHSmirth

    What do you mean don't use goto, you've just made my childhood redundant.

    10 print "Mike woz ere!"

    20 goto 10

  30. Donkey Molestor X

    you make ken and dmr sad

    got a thought for y'all:

    Ken Thompson and Dennis Ritchie did the real heavy lifting by designing and building the original Unix.

    They managed to do this without being assholes.

    So why does anybody think you need to be an asshole just to make a mere copy of Unix?

    1. Peter Gathercole Silver badge
      Boffin

      Re: you make ken and dmr sad

      Whilst I completely agree with your sentiment, you have to realise that the last UNIX kernel worked on by those luminaries was tiny compared to the current Linux kernel. It did not even have a huge amount of networking code in it.

      After UNIX Version/Edition 8, They moved on to Plan 9, which was written in a completely different way (much more like a micro kernel), and left UNIX in the hands of the UNIX Systems Division in AT&T.

      It was written in a very portable way, but even the kernel itself from USD was intended to be compiled by UNIX's own Portable C Compiler. Back in the day, it caused more problems and fragmentation for vendors doing their own ports using their own compilers than anything else! It was only after the standardisation attempts of SVR4 and OSF/1 in the late '80s and '90s that the vendor kernel code bases started converging again.

    2. PaulFrederick

      Re: you make ken and dmr sad

      Times change so tactics have to adapt too.

  31. J J Carter Silver badge
    Trollface

    Garbage In...

    No wonder the shareware OS enjoys a rounding-error market-share. Just saying.

    1. sabroni Silver badge

      Re: Just saying.

      Just saying that you've never heard of web servers?

      1. война и мор Silver badge

        Re: Just saying.

        Or mobile phones?

        It's the desktop UIs that have rounding error market share, and they aren't Torvald's problem.

    2. Anonymous Coward
      Anonymous Coward

      Re: Garbage In...

      No wonder the shareware OS enjoys a rounding-error market-share. Just saying.

      Well, to be fair Microsoft only released Windows 10 on desktops a few months back and is yet to release it for phones. It'll be a long time before it reaches the popularity of Android and it still has a long way to go before it can match Linux in the data centre.

      (Yes, it can run a web server, but until very recently, the footprint was huge. The "nano" version of Windows has not been around anywhere near as long as what the equivalent Linux distributions have.)

  32. Anonymous Coward
    Anonymous Coward

    Question

    Can anyone who dislikes Linus Torvald just go off and fork the kernel?

    Or does that risk a nuclear explosion?

    (Just askin'...)

    1. Vic

      Re: Question

      Can anyone who dislikes Linus Torvald just go off and fork the kernel?

      Yes. It's GPLv2, so as long as you fulfill that licence, you are perfectly at liberty to fork it and maintain your own version.

      Guess how many people do...

      Vic.

    2. Anonymous Coward
      Anonymous Coward

      Re: Question

      Freescale pretty much do. They take an old stale version of the kernel (at least 12 months old), pile their patches on, and release it to their community.

      The kernel is different enough to be a "fork", and only a small portion of the patches wind up going back upstream into the main-line kernel.

      This creates headaches for the system integrators using Freescale chips, as they have to trade-off having the Freescale kernel tree that supports some of the SoC hardware better, versus a newer kernel that has features needed to make non-SoC hardware work better.

      Or they wind up having to support frankenkernels like the one I did for Jacques Electronics, which used the Freescale 2.6.28 kernel, but had a back-ported version of ALSA System-on-Chip framework taken from kernel 2.6.33/2.6.34 (then latest).

  33. Kwll

    Some need to man up, and dislodging their heads from the sand without whining would be useful too.

    Let's handle it logically.

    A writes code

    B has more experience than A

    B review that code and shit hits the fan

    A starts whining about his precious code being shred to bits.

    Seriously? What do we need now, kindergartens for adults?

    There is a huge difference between a personal assault and an experienced criticism to a sloppy job. Time to grow up?:)

    Cheers

    Alessio

  34. sisk Silver badge

    As usual I wish Torvalds would dispense with the profanity, but at least it's not a personal attack this time. And, also as usual, he's absolutely right. That's some of the most hair-brained code I've ever seen.

  35. badger31

    When you're right, you're right.

    But you don't need to be such a dick about it.

  36. fred 32

    "abuse"

    These are adults being called out on professional issues, either put up or shut up, your feelings don't matter.

    Enough bad code exists to cause performance and security nightmares, people need to start caring.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019