An interesting software event occurred today: I fixed a bug in a “C” program, which I have known must exist for about 10 years. During those years, I’ve made several concerted attempts to find this particular bug, but I never could pin it down. It was a rare glitch in a system with many major glitches, so fixing it was only a quixotic quest for perfection, not a necessity. I finally stumbled into a repeatable test case while debugging some newer code.
What has this got to do with “C”? The bug was a simple fencepost error, where a buffer was overrun by 1 byte. This could have been detected automatically, and would have been in some more modern languages. It’s not clear that this could have been detected by anything other than a permanent runtime system which always checks – a specialize test environment might have run for years without producing the right kind of input data.
I worry about the uncountable millions of lines of “C” code that run everything from my desktop computer to the planes I fly in. They can’t really be replaced or rewritten. “C” is an easy target because it’s such a wonderful language for producing buggy code.
My top ten list of way to be screwed by “C”
This happened to be a type of problem that could have been detected automatically. There are plenty of other bugs that can’t be found that way, or by any known method. In some sense, the worst bugs are the ones you don’t know exist until you see a result you don’t like. There’s no way to avoid those.
