Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming Open Source

Linus Rants About C Programming Semantics (iu.edu) 576

Posted by Soulskill from the old-man-and-the-C dept.
jones_supa writes: "Christ people. This is just sh*t," begins Linus Torvalds in his message on the Linux Kernel Mailing List. Torvalds is grumpy because some new code added to the IPv6 subsystem has created conflicts. "The conflict I get is due to stupid new gcc header file crap," he writes. "But what makes me upset is that the crap is for completely bogus reasons." The new improved code uses fancy stuff that wants magical built-in compiler support and has silly wrapper functions for when it doesn't exist. Linus provides an alternative that contains a single and understandable conditional, which looks cleaner and generates better code.
This discussion has been archived. No new comments can be posted.

Linus Rants About C Programming Semantics More

Linus Rants About C Programming Semantics

Comments Filter:

  • Linus rants about EVERYTHING (Score:3, Insightful)

    by NotDrWho ( 3543773 ) on Monday November 02, 2015 @09:44AM (#50846169)

    Film at eleven

  • Not programming semantics, but the coder (Score:5, Insightful)

    by QuietLagoon ( 813062 ) on Monday November 02, 2015 @09:48AM (#50846189)
    Gawd, that code was ooogly.

    .
    Such code is the result of coders who rely on the compiler too much, and their brains too little.

    .

    "You and I learned C when it was programmers, not compilers, which had to be intelligent."

    - - - Terry Lambert

    • Re: (Score:2, Interesting)

      by thedonger ( 1317951 )

      .Such code is the result of coders who rely on the compiler too much, and their brains too little.

      I work in .Net -- *ducks* -- and it happens quite often that people rely on Intellisense and the fact that their code compiles as validation it is correct. We don't have to allocate memory, so we don't think about how we use objects that require database calls; we don't think about scope; there's a plug-in that will refactor code for you, so there's another crutch to give us more time to think about what we will be doing when we get off work.

      Also, get off my lawn.

      • Re: (Score:2)

        by cdrudge ( 68377 )

        If only Slashdot had some type of crutch to tell you when you didn't properly close your <blockquote>.

        I've done it too so I'm not innocent either, but sometimes even people who do use their brains can benefit from relying on tools to help them out from time to time.

        • They do -- it's called the "preview" button. But it only works when the user looks at the preview prior to pressing "submit."

    • Re:Not programming semantics, but the coder (Score:4, Funny)

      by Damouze ( 766305 ) on Monday November 02, 2015 @09:55AM (#50846249)

      Reminds me of a friend of mine who used to check if a pointer was NULL, then if it was not and finally for other cases:

      if(!p)
      { ...
      }
      else if(p)
      { ...
      }
      else
      { ...
      }

      His reasoning: the compiler could have a bug and this way you would catch that bug.

      • Re: (Score:2)

        by DrXym ( 126579 )
        Well it could happen if there was a race condition (e.g. p is shared with another thread) and p changed from not-NULL to NULL between the first test & else jump. But if that were the case then there is something seriously screwed up with code, starting with the person who wrote it.

        More ordinarily you have assume that the compiler generates correct code and if it doesn't, particularly on something as trivial as an if-else then really you shouldn't be using that compiler.

        • Re: (Score:3)

          by Sigma 7 ( 266129 )

          Modern compilers won't notice the pointer changing between those two conditionals, with it being loaded into a register that won't be modified in another thread. Some compilers may realize that it's impossible to enter the third block, and simply purge the code. In either case, the third block is pure fluff that should be removed.

          If you're in the rare situation where said pointer can change suddenly, then you should:

          • Declare the pointer as volatile.
          • Copy the pointer to a non-volatile variable
          • Use synchroniz

      • Re:Not programming semantics, but the coder (Score:5, Funny)

        by wonkey_monkey ( 2592601 ) on Monday November 02, 2015 @10:43AM (#50846647) Homepage

        His reasoning: the compiler could have a bug and this way you would catch that bug.

        That's why all my variables are upper case and only use vowels. One day there might be a bug with lower case consonants, and then all you suckers will be laughing on the other side of your faces!

      • His reasoning: the compiler could have a bug and this way you would catch that bug.

        Well, I'll give him one thing: Any compiler that accepts this code without at least giving a warning about dead code does have a bug (unless p is volatile). So it does detect buggy compilers.

      • To be honest, this is something I would also do on slightly more complex sequence of if-then-else-if that are supposed to try all possibilities. Similarly, I always try to enforce the 'default:' on switch statement even if I know that all possible values are tested.

        That may be unnecessary at the time I write the code but that can save my ass if someone decides to make a small 'harmless' change in a few months or years.

        The funny thing is that in C++, it is actually possible to reach the final 'else' assuming

  • GOOD. He's doing his job (Score:3, Insightful)

    by Anonymous Coward on Monday November 02, 2015 @09:59AM (#50846285)

    Linus is doing his job, making sure that the Linux kernel code continues to maintain quality and supportability. I read the thread, the code is shit, and Linus called it out. I don't care about his language or the tone of his message. He's right. Linus could stomp kittens flat and I wouldn't care, as long as that kitten-stomping was in the pursuit of making the Linux kernel better. Enough of this fake controversy about Linus and his communication style, already.

    • Re: (Score:3)

      by plover ( 150551 )

      Linus could stomp kittens flat and I wouldn't care, as long as that kitten-stomping was in the pursuit of making the Linux kernel better.

      To be fair, next Thursday is Finland's national Kitten Stomping Day, so it might not be purely in pursuit of improving the kernel.

  • So he rants and raves and bitches and moans... It shows that he is passionate and serious about what he does.

    Now, if only Bill Gates would learn to rant and rave passionately about the quality of his product - instead of counting his coins and pretending to be a philanthropist.

  • I wonder if... (Score:3)

    by m.alessandrini ( 1587467 ) on Monday November 02, 2015 @10:07AM (#50846339)
    ... all the other people over there could use such a language, even for "legitimate" reasons, and get away with it.

  • Have a Snickers Linus (Score:5, Funny)

    by CMOS4081 ( 1700876 ) on Monday November 02, 2015 @10:09AM (#50846351)
    You turn into Steve Jobs when you are hungry.

  • Linus is right. (Score:5, Insightful)

    by Anonymous Coward on Monday November 02, 2015 @10:09AM (#50846357)

    It's horrible, horrible code.

    I'm not a C developer, but I know C and have been developing for 20+ years in various other C like languages. The thing Linus is ranting against is absolutely true. The first example is very clear what it does. Assign a variable. The second (new) code is fucked up, and completely unclear what's going on. Check some kind of boundary condition, then some weird shit going on that I don't understand?

    The 3rd example is back to clarity. Check some boundary conditions, then assign the variable. I'd have never guessed the 2nd example does that without reading the 3rd.

    I also happen to agree with Linus about not "toning it down". There's other ways to manage the kind of stupid bullshit that goes on in software development, but one effective way is going apeshit over shit like this. Linus's way isn't the ONLY way, but it does work. Developers tend to be filled with prima-donnas that think everything they produce is gods gift to coding. Sometimes the only way to get through is just yelling at the top of your lungs about shitty fucking code.

    We live in an increasingly hyper-sensitive society where some people want to control speech in a fascist way. I'm so tired of all this bullshit about how it's "disrespectful to women", or other such crap. That seems to be the garbage dump reason for everything someone doesn't like that doesn't fit somewhere else. Just claim rascism, sexism, etc, even when it totally doesn't fit.

    Oh, and please stop with the "The LEFT is trying to silence us.. blah blah blah" nonsense. This isn't "The Left" any more than the westboro babtist church are christians, or the nutjobs that open carry guns into Starbucks is "The Right". All of those are just radical elements of the political divide that have inserted themseves where they get the least criticism for their crazy ideas.

    • Re:Linus is right. (Score:4, Informative)

      by Polizei ( 1782856 ) on Monday November 02, 2015 @10:57AM (#50846791) Homepage
      Not to state the obvious, but here's the definition of `overflow_ubus`

      static inline bool overflow_usub(unsigned int a, unsigned int b,
      unsigned int *res)
      {
      *res = a - b;
      return *res > a ? true : false;
      }

      So the 2 conditionals from the patch are completely idiotic and wrong.
      `overflow_ubus` not only makes an unnecessary assignment to `mtu`, but does a check after that assignment, and then you need another check for it outside of `overflow_ubus`.

      In general, the proposed patch conditionals could be rewritten as

      unsigned int oldmtu = mtu;
      mtu -= hlen + sizeof(struct frag_hdr);
      if (mtu > oldmtu || mtu <= 7)
      goto fail_toobig;

      Now that's ugly!
      • Not to mention that sizeof forces hlen+sizeof(struct frag_hdr) into size_t, which very probably is not unsigned int (it is not, on any of the systems I've owned for the last decade at least). Therefore overflow_usub is seriously bogus in and of itself.

  • Incorrect headline (Score:4, Informative)

    by Dog-Cow ( 21281 ) on Monday November 02, 2015 @10:13AM (#50846381)

    Not that this will surprise much of anyone, but the headline is wrong. Linus did not rant about C programming semantics. He ranted about a specific C function and the style used to perform a sanity check.

  • Microaggressions (Score:2, Funny)

    by Anonymous Coward

    I have NO IDEA who this Linus guy is, but his microaggressive behavior will not be tolerated in the Open Source community. I doubt he was much of a contributor to Open Source, but we need to ban him as he is creating a toxic environment in my safe space. No big loss.

  • Is there a use for overflow_usub? (Score:4, Insightful)

    by 91degrees ( 207121 ) on Monday November 02, 2015 @10:19AM (#50846427) Journal
    Seems that overflow_usub() will always be less readable than a condition then a subtraction. It's a pretty obscure function - searching for it reveals most of the discussion is about this specific patch. It will save an instruction or two with appropriate compilers, by using the JC instruction rather than a CMP/JZ and in really performance critical code this will matter, but most code benefits more from readability than that extra instruction.

    • Re: (Score:3, Informative)

      by Anonymous Coward

      http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0103r0.html

      I guess the compiler developers and the IETC are all just idiots.

      We use these functions in HFT all the time. Too bad it's too "complicated" for kernel developers to understand...

  • Just curious what it looks like in context.

  • Cramming a simple conditional into a weird, side-effect-producing function is just horrible.

    And next thing, someone who doesn't know about short circuit evaluation in C will swap the two conditionals.

    • Re: (Score:2)

      by fisted ( 2295862 )

      someone who doesn't know about short circuit evaluation in C will

      be unlikely to write kernel code, much less submit upstream

  • Disagree with the language used... (Score:3, Insightful)

    by mseeger ( 40923 ) on Monday November 02, 2015 @10:32AM (#50846523)

    Two points:

    a) I agree with him on the code, but I am not a competent coder myself.

    b) I disagree with the form of communication and that is an area where I am competent.

    As Linus expects others to write proper code, I expect people to conduct proper communication.

    Same rules apply: If it does not improve the flow of information, it does not belong in the email. Some swearwords don't bring any points across that could not be covered by "professional english" subset ;-). I think "sh*t" and "crap" may be considered validly applied here. But beyond that, it generates an unnecessary conflict at rc7 time. ï

    • Re: (Score:3)

      by bsolar ( 1176767 )

      As Linus expects others to write proper code, I expect people to conduct proper communication.

      Linus expects proper code from those who contribute to his project: what you do in your own project is your business. Similarly, you are free to expect people to conduct "proper communication" within the communities *you* control, but not to force your expectations to communities *other people* control.

  • Shiny loses out again (Score:3)

    by smooth wombat ( 796938 ) on Monday November 02, 2015 @10:40AM (#50846609) Journal
    The new improved code uses fancy stuff that wants magical built-in compiler support

    Imagine that. Someone thinking, "Ohhh, shiny! Let's try this because it's new and cool."

    Instead of, "I need something to get the job done in the simplest fashion."

    There's a reason analog light switches are still around. They just work. No bullshit about having to talk to a computer to decide what to do. Clean and simple. Just like code should be.
  • "A shiny function that we have never ever needed anywhere else, and that is just compiler-masturbation."

  • reality (Score:4, Interesting)

    by colfer ( 619105 ) on Monday November 02, 2015 @11:33AM (#50847137)

    Hannes seems to have a valid point that boundary checking should be standardized in some way. Rasmus backs him up and mentions the result of the rant is they'll end up discarding his more comprehensive work on the issue: http://lkml.iu.edu/hypermail/l... [iu.edu]

    Linus seems to be saying all boundary checks should be ad-hoc because the new syntax is to hard to GET OFF OF HIS LAWN. Because it is dog poop.

    • Re:reality (Score:4, Informative)

      by ledow ( 319597 ) on Monday November 02, 2015 @11:40AM (#50847223) Homepage

      The new syntax only works on certain versions of the GNU compilers. It's also more convoluted, just as easy to get wrong (i.e. the guy himself admits there's a possibility of the same kinds of mistakes as without it), non-standard, and harder to read - especially if you are unfamiliar with a GNU-only syntax.

      Read the rant, then look at the code.

  • clever morons (Score:5, Insightful)

    by iggymanz ( 596061 ) on Monday November 02, 2015 @11:33AM (#50847147)

    open source world is getting overrun by high IQ morons, that put in bloat, hyped fads, and needless complexity. they indulge in mental masturbation rather than good design

  • Does kernel have numeric overflow vulnerabilities? (Score:3)

    by ljw1004 ( 764174 ) on Monday November 02, 2015 @11:49AM (#50847289)

    Like Linus, I also write the simpler form of this kind of code when writing in C/C++.

    Unlike Linus, I feel bad about it! My colleagues point out places where arithmetic overflows might lead to crashes. Honestly I find it really difficult to think through the overflow issues for *every single* plus, minus and multiply operator in my code. I think it's like cryptography in that sense -- most regular programmers, including good programmers, don't look at arithmetic operators from the perspective of attackers.

    In this case, does Linus' code have the exact same behavior on all possible inputs including overflow-causing inputs? If not, which of the two behaviors is the desired one?

    Are there places (maybe including this one) where the kernel code doesn't guard properly against arithmetic overflow? Will the newfound attention bring hackers scrutinizing it for overflow flaws?

  • Linus is right only for people of his caliber.... (Score:5, Interesting)

    by Wrath0fb0b ( 302444 ) on Monday November 02, 2015 @11:58AM (#50847407)

    Both in the technical sense and in the human sense.

    Technical: People at Linus' caliber understand exactly the rules for signed/unsigned integer promotion and where underflow is defined (as wrap) and where it's undefined[1]. Consequently he wrote perfectly-correct code for detecting the underflow and bailing out safely. Programmers at mere mortal levels of skill, however, routinely mess this up, often causing exploitable security bugs (believe me, I do code security audits as part of a real honest living). My advice for everyone (contra Linus!) is always always always use the compiler intrinsics [gnu.org] for integer math. Feel free to decline this advice if you are a Linus level wizard (if you were, of course, you would already feel free to decline it) but if you have to wonder if you are, you probably aren't.

    Linus seems to think that the kernel should only be written by folks that don't need that kind of help -- and for that I won't argue with him. It's his baby and he can chose whether to have a small number of über-developers or a larger number of mortals. Which goes straight to the second point:

    Human: People at Linus' caliber thrive on negative feedback. At their level, positive feedback means nothing because there's nothing he can learn from someone praising his work. He wrote a kernel, he knows he's good. Meanwhile negative feedback is useful (unless trivially discountable): if the complaint is right, he'll correct something he was doing wrong; if the complaint is wrong, he'll be forced to think through why. In any event, he could never imagine why someone would sugar-coat their opinion on any matter.

    So it seems like his mode of communication is meant to answer that question for the former: he wants people of his caliber that don't write ugly code using arithmetic crutches and don't care about strongly worded criticism. There's nothing invalid about that either -- maybe it's true that the best model is that Linuses work in the kernel and the rest of us go up into userland where we use crutches like memory protection and higher-level constructs :-)

    [1] And when behavior is undefined, a smarter compiler can remove the code-path entirely -- the kernel itself was hit by such a bug [lwn.net] where GCC legally removed a NULL check because the pointer was dereferenced before the check. See also this reference. Then there's the sad fact that people still argue against the clear language rules that say that assert( 100 + some_int > some_int ); can always be optimized away [gnu.org].

  • Developers following the KICC principle (Score:4, Insightful)

    by bradley13 ( 1118935 ) on Monday November 02, 2015 @01:36PM (#50848443) Homepage

    KICC = Keep it Complicated and Crappy

    I recently ran into a similar example in Java, where Java 8 has introduce the class java.util.Optional. This is used by certain other Java 8 classes as a return type.

    What does Optional do? It provides an object that contains an object. If that inner object is null, the method isPresent() returns fall. So now, instead of:

              if (widget != null) { widget.doSomething()) ... }

    You can write

              if (optional.isPresent()) { widget = optional.get(); widget.doSomething()) ... }

    Of course, if you don't quite trust the class giving you the Optional, you get to write

              if (optional != null && optional.isPresent()) { widget = optional.get(); widget.doSomething()) ... }

    This serves no useful purpose, except to make code more complex. Stupid, stupid, stupid...

    The claim, of course, is that this marvelous class is designed to work with lambdas. The thing is, lambdas themselves are an idiocy in Java. Lambda expressions are inherent in purely functional languages, but they are semantically out of place in a declarative language.

  • BOTH code Snipets have readability Problems (Score:3)

    by williamyf ( 227051 ) on Monday November 02, 2015 @04:16PM (#50850011)

    If you do not know what usub is, is difficult to determine what is is doing. In that, Linus is right. But look inside the Parenthesis:

    " (mtu, hlen + sizeof(struct frag_hdr), &mtu) || mtu = 7) "

    Here is a very Clear OR. The guys are checking for the MTU Being to big OR too small...

    Linus offers this code:

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

    Which obfuscates the OR comparison...

    And Both Call the label "fail_toobig" intead of a more readable "fail_MTU_outofbounds"

    Or am I missing Something?

Slashdot Top Deals

The Tao is like a glob pattern: used but never used up. It is like the extern void: filled with infinite possibilities.

Close