Originally published on: Fri, 7 Oct 2011.
The Y2K panic was not the first time I had encountered a date-oriented software bug. Years before Y2K problems were even a worry, I ran into a situation where an MS-DOS program written in C began to run amok on October 10th.
There had been no new releases of this particular program in months. It had behaved normally running continuously on an unattended PC in a computer room. Operators checked the computer every once-in-a-while to make sure that the messages on the screen were being updated. When they saw an error on the screen, they informed us that there was a problem.
We began to try to solve the problem by looking through the code and possible changes that could have occurred to the environment. We went over everything and had determined that there’d been no operating-system patches, nor updates to any of the files that could have affected the program.
The only thing that had changed before the problem manifested was the date.
The problem manifested as a hard-crash without any real debugging info present. We didn’t often have the luxury of stack-traces, remote debuggers or things like that, so we kept trying to piece together where it was blowing up by introducing diagnostics into the code; re-release, re-test, …etc.
The problem?
We were calling a function that placed the current date into a buffer in MM/DD/YY format. The buffer had been defined as a char[8]. Yes … I know. A char[8] buffer only has enough room to hold the digits and the slashes and not the trailing string-terminator character. Yet, we didn’t trip over this until October 10th.
October 10th happens to be the first day of the year where the month and day are both two-digit numbers. Since we had suppressed leading zeroes from the month and the day when formatting the date, there was never a combination of months and days that ever overflowed our buffer … until 10/10.
We changed the buffer declaration to char[9] and the program was healthy once again.
Jim Lawless' Blog 