On the subject of catastrophic failures: I've written a lot of code that's in front of a lot of people. Little things like >= instead of == have made situations "manageable" where they might not otherwise have been. The appearance of being a little sloppy in a critical situation is far better than causing a disaster.
in reply to Re: Defensive Programming
in thread Defensive Programming
You can never test enough. You can never design enough. The OP gave a trivial example. Wish he'd have had something better up his sleeve.
Lemme give some examples (yes, these have actually occured):
I'm gonna get --'d by the purists sure, but in my head as I'm writing these things I always thing "what if this loop gets away..." and imagine the worst (sometimes it's not that bad, or not possible). Murphy's an old friend of mine. He's not to be poo-poo'd with blanket statements of "better engineering". Sometimes this is better engineering.
- Old-time reporting system keeps line-counts to know when to issue a form-feed character. Change made to the footer of a report by a sloppy programmer caused the == condition to miss by one and the form-feed routine goes nuts and spews paper everywhere. This is not funny on a high-speed chain-printer with access to a 50lb box of paper. Or on a check printer where each check skipped costs money.
Fixed the bug, changed the condition to >= and when a subsequent programmer caused a similar bug we got a few pages that printed with "widow" lines -- a far, far better problem.
- Medical records system contained a hash-and-sequential-search feature for finding individual records. Large installations notice a (o)n time for finding records when it should have been constant time plus a small hit for the sequential search. When a doctor is trying to find your drug allergies in a hurry, this isn't funny either.
Turns out a programmer didn't notice that certain overflow conditions (hash collisions) near the end of the file caused a sequential search to wrap to the beginning of the file again without returning the failure. Small bug fixed, and a == changed to a >= ensured that if it ever cropped up again at most one additional sector of records would be read. (And it did, sector drops from the disk caused it to skip a sector and only a >= would catch it...)
- Countless small C and ASM programs I've seen where a "hang" problem has been introduced by an unforseen increment and a == missing slightly. This always happens in a demo or at a customer site. (Hi Murphy!) The "hang" eventually clears itself up after you wrap around a short, int, or long. If you've got an index variable with many friends in a block of code, defensive is always good.