Integer Overflow And Underflow

-
Glass overflowing with water

Q: When is optimization sub-optimal? 

A: When it creates an Android bug that crashes your phone during a call to 911.

Details of the bug can be found in Ars Technica, but I want to focus on the integer overflow/underflow that caused the crash:

return account1.hashCode() - account2.hashCode();

Nevermind the variable names and the invocation of hashCode(). The problem is subtracting without looking, and returning a number that might be too large or too negative for the program to handle.

Google corrected the code by using the Java compare() method:

return Integer.compare(account1.hashCode(), account2.hashCode());

which limits the return values to -1, 0, or 1, indicating account1 is less than, equal to, or greater than account2, respectively.

This raises two questions: "Why did the original code use subtraction?" and "Wasn't this tested?"

Addressing the first question, I've seen overflows and underflows before, and even wrote about them in Space, Time, and Imagination Have No Boundaries, But Your unsigned char Does.  Evidently, ignoring boundary conditions is common.  Doing so is not an error of inexperience either, as I have noticed junior and senior developers alike make this very mistake.  Rather, this code can better be described as an affliction of micro-optimization.

Among some developers, there is an urge to make every line of code carry its own weight, where only the briefest, fastest code will do. In the end, added performance is negligible, whereas added risk takes one step toward reality.  Subtracting without looking is not too different from driving a car and changing lanes without looking.

Back when computers were slow and compilers immature, these micro-optimizations did matter somewhat. I've folded strings, unrolled loops, removed unneeded braces even though they provided legibility, and declared loop counters in the C language as register int i.  Today's compilers are robust, and render these measures unnecessary.  Meaningful optimization takes place at the program design level, and only after determining that the program runs correctly (see Dijkstra). 

Which brings us to the second question regarding testing. This bug only showed itself when the Microsoft Teams App was installed, and even then, only under rare circumstances. As a developer, it's fun to blame QA for missing the bug, but realistically, QA can't possibly test this with every third party app in existence. Nothing would ever get released. No, the blame falls squarely on the shoulders of the developer, who should have been more defensive in his or her code.

Unit testing is a lot less expensive than QA integration testing, which in turn is a lot less expensive than finding a bug in production. First principles matter. I doubt I've seen the last of overflow and underflow errors, but resisting the call of micro-optimizations will go a long way toward producing more reliable programs.



Comments

Post a Comment

Popular posts from this blog

MR2 Check Engine

-
Image
Shown here is the 1991 Toyota MR2. Thanks to the mechanical skills of a family enthusiast, it purrs, growls, and turbo whistles like a dream.   My hardware ability doesn't go much further than oil changes. Rather, my expertise is in software, and I wrote an Android App (iOS version is in progress) to diagnose the flashes of the check engine light. This second generation MR2 predates the OBD2 connector, a standard used to diagnose engine, transmission, and emissions problems quickly and easily. Instead, we have a flashing check engine light which needs some deciphering, followed by a lookup in the service manual. Basically, you count flashes to arrive at fault code number. A short pause (~1.5 seconds) indicates the start of the next digit. A medium pause (~2.5 seconds) indicates start of the next fault code. And a long pause (~4.5 seconds) means the sequence has ended and will repeat. The video below corresponds to the codes 41 and 51. Using the the MR2 Check app and selecting the 3
Read more

Bookshelf: UNIX A History and a Memoir

-
Image
  A man page will give you, in black and white, specific information about UNIX. Brian Kernighan's new book adds color and depth about UNIX you won't find anywhere else. I'm not a gray beard (yet), but I imagine they would plow through the book knowingly, but at the same time, learn a few things. Those new to UNIX -- recent college grads or those experimenting with Raspberry Pi -- would be better off starting with Chapter 8 which describes more relatable events and the descendants of UNIX, including Minux and Linux. It's when they start to ask questions like "Where does UNIX come from?" and "Why is Gamora grep?" that they should start from the beginning: Bell Labs, 1969. Kernighan opens with a birds-eye-view of Murray Hill New Jersey, zooms in on the buildings, the offices, the significance of Center 1127, and offers a brief look at some of the key players there. As I progressed through the book, the two factors that made UNIX not just possible, bu
Read more

Bookshelf Classic: The C Programming Language

-
Image
My first job had me programming in Microsoft BASIC for the IBM PC (DOS).  BASIC worked well enough, but its limitations were clear.  The language was interpreted and therefore slow.  More importantly, it wasn't a modern structured language, and instead, relied on line numbers and the GOTO statement.  Anyone who has read Dijkstra knew  GOTO was a bad thing . Having learned a structured language in college ( PL/I ), using BASIC felt unnatural.  When a C compiler became available for the PC, I saw a chance to improve and modernize our software.  The problem was selling the idea -- a problem made harder because I wasn't fluent in C. "It would be a staffing problem.  Not many people know C, but we can find a lot of programmers who know BASIC," noted one manager. The argument was strong as my knowledge of C was weak.  But I knew that C, by design, was a small language and thus easy to learn.  "It has about 30 keywords," I proffered to another manager. U
Read more