Linus Torvalds Over Flows On Overflows In C |
Wednesday, 15 May 2024 | |||
You may think of Linus Torvalds as the Linux guru, but he is also a leading expert on C and often ignored and misunderstood in this role. A recent exchange on the Linux Kernel mailing list demonstrates just how big the gap can be. And, yes, it's an example of Linus at his explosive best! We all know about arithmetic overflow and most of us think it's a bad thing - something to be avoided at all costs. We can point to horrendous examples of computations that failed because the original programmer chose too small a variable type to hold the result of an operation in all cases. So most programmers think that overflow should be tracked down and flagged by static analysers if at all possible. Except, of course, any reasonable C programmer who knows about bits and how things work, knows that overflow, or wrap-around in the unsigned case, is far from undesirable - it is a powerful tool and often used to achieve something perfectly sensible. You could say that this understanding is a good test of whether or not a C programmer is a real C programmer or an escapee from a high level language. The point is also that C is like this, not because it is a 50-year old throwback and a primitive language, but because it serves the purposes of low-level programmers like Linus who know their bits. So when Kees Cook, a Google programmer, started a discussion of how to deal with overflow in the kernel, you could have known that something was about to hit the fan. Cook suggested using a sanitizer to scan the code and flag possible overflow errors or to introduce operator overloading and explicitly allow the programmer to handle the error. Linus responded quickly, pointing out that: "The thing is, wrap-around is not only well-defined it's *common*, and *EXPECTED*." He goes on to explain the sort of places it is used to good effect. In computing a hash value, for example, wrap-around is part of the computation. He also points out that wrap-around is actually used to detect overflow: unsigned int a,b; Compare this to the ludicrous situation we find ourselves in with the signed version of this program. In this case signed overflow is undefined behavior and this designation allows compiler writers to simply state that signed overflow cannot happen in a valid program - so they delete the test! This makes testing for signed overflow very difficult without resorting to compiler- or machine-specific tricks as you have to detect it before it happens. Linus went on to say that "a tool that complains about wrap-around in the and "Put another way the absolute first and fundamental thing you should look at is to make sure tools do not complain about sane behavior." This is getting to the heart of the matter. A real C programmer would find wrap-around perfectly sane behavior. What might surprise you at this point is that from here the discussion becomes much more reasonable with Linus outlining some conditions in which things might go wrong in ways that are unexpected. He points out that sometimes we get unsigned arithmetic without realizing and that there are patterns which suggest unsafe wrap-around - for example when computing the size of something. The real thing that Linus is trying to protect us from is: "Don't think of wrap-around as some "global evil" Read the rest of the exchange. It neatly illuminates the difference between C and other languages.
More Information[RFC] Mitigating unexpected arithmetic overflow Related ArticlesLinus Returns A Reformed Character Linux Adopts New Code of Conduct; Linus Apologizes and Takes a Break Linus On Linux And Strong Language GCC Gets An Award From ACM And A Blast From Linus Linus Torvalds Receives IEEE Computer Pioneer Award Linus Torvalds interview - the early years Linus Torvalds is now a US Citizen To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.
Comments
or email your comment to: comments@i-programmer.info |
|||
Last Updated ( Wednesday, 15 May 2024 ) |