Embedded Muse 80 Copyright 2003 TGG January 25, 2003


You may redistribute this newsletter for noncommercial purposes. For commercial use contact info@ganssle.com.

EDITOR: Jack Ganssle, jack@ganssle.com

CONTENTS:
- Editor’s Notes
- A Fascinating Study
- Jobs
- Thought for the Week
- About The Embedded Muse


Editor’s Notes


I wrote a three-article series in Embedded Systems Programming about watchdog timers. The first appeared this month and has generated a tremendous amount of reader feedback. So, if watchdogs and/or reliable firmware are important to you, check it out in the print edition of the magazine or at www.embedded.com.

I'll present my Better Firmware Faster seminar in Melbourne and Perth, Australia February 20 and 26th. All are invited. More info here. The early registration discount ends January 20.


A Fascinating Study


Researchers at Stanford have just released a paper detailing their use of automated tools to look for redundant code in 1.6 million lines of Linux. “Redundant” is defined as:
- Idempotent operations (like assigning a variable to itself)
- Values assigned to variables that are not subsequently used
- Dead code
- Redundant conditionals

(The authors did eliminate the oddball cases where these operations are important, like in setting memory mapped I/O.)

They found that redundancies, even when harmless, strongly correlate with bugs. Even when the extra code causes no problems, odds are high that other, real, errors will be found within a few lines of the redundant operations.

In their words “The results indicate that (1) files with redundant errors are good audit candidates and (2) redundancy correlates with confused programmers who will probably make a series of mistakes.”

Block-copied code is often suspect, as the developer neglects to change things needed for the code’s new use. Another common problem area: error handlers, which are tough to test, and are, in data I’ve gathered, a huge source of problems in deployed systems.

The authors note that their use of lint has long produced warnings about unused variables and return codes, which they’ve always treated as harmless stylistic issues. Now it’s clear that lint is indeed signaling something that may be critically important.

The study makes me wonder if compilers that optimize out dead code to reduce memory needs aren’t in fact doing us a disservice. Perhaps they should error and exit instead.

Get the study at www.stanford.edu/~engler/p401-xie.pdf.


Jobs


Thought for the Week


The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.