There is a joke in the software development community that “it’s not a bug. It’s an undocumented feature.” It’s typically used when a bug is too hard to fix or that is ordinarily harmless. Depending on such bugs is not a good idea though. Some people ignore the risk though.
Many years ago I was working for a company that made some great hardware and, well, let us say, less impressive software. One of their products was a FORTRAN compiler. FORTRAN has a FOR loop – a counting loop. The language specification calls for the loop to determine if it should continue at the top of the loop.
FOR loops have a starting and ending value. These values can be held in variables and if the loop determines that the end value is greater than or higher than the starting vale, if counting up, that the loop will not execute. This company’s compiler checked at the bottom of the loop. This violate the specification and created a situation where the loop always executed at least once.
One of the customers I was supporting took advantage of this bug. They did it often. Unfortunately the company I worked for came out with a new version of the compiler. This version was outstanding. It was one of the first optimizing compilers and generated very fast, efficient code. The developers were also extra careful to make sure it confirmed to the official language specification. So the customers programs broke.
I got the call from their VP of software development and explained what happened. Being a smart guy, he realized that the fault lay with his developers and not our software. Crisis averted for me. Some extra work for the customer’s development team. Hopefully, the developers learned to understand how software was supposed to work and not take “advantage” when it worked differently.
The software learning stories series:
No comments:
Post a Comment