Why Language Features Matter—The Way the Fortran Bug
Really Happened!
The details of a programming language really matter. They matter because the details make the
difference between a reliable language and an error-prone one. This was dramatically revealed in
Summer 1961 by a programmer at NASA, testing a Fortran subroutine used to calculate orbital
trajectories. [1] The subroutine had already been used for several brief Mercury flights, but it was
mysteriously not providing the precision that was expected and needed for the forthcoming orbital and
lunar missions. The results were close, but not quite as accurate as expected.
[1] The story is very widely misreported, and inaccurate versions appear in many programming language
texts. Indeed, it has become a classic urban legend among programmers. The definitive account, from Fred
Webb who worked at NASA at the time and saw the actual source code, can be seen in "Fortran Story—The
Real Scoop" in Forum on Risks to the Public in Computers and Related Systems, vol. 9, no. 54, ACM
Committee on Computers and Public Policy, December 12, 1989.
After checking the algorithm, the data, and the expected results at great length, the engineer finally
noticed this statement in the code:
DO 10 I=1.10
Clearly, the programmer had intended to write a DO loop of the form:
DO 10 I=1,10
In Fortran, blank characters are not significant and can even occur in the middle of an identifier. The
designers of Fortran intended this to help cardpunch walloppers and to aid the readability of programs,
so you could have identifiers like MAX Y. Unfortunately, the compiler quite correctly read the
statement as DO10I = 1.10
Variables do not have to be declared in Fortran. The statement as written caused the value 1.1 to be
assigned to the implicitly declared floating point variable DO10I. The statements in the body of the
intended loop were executed once instead of ten times, and a first approximation of a calculation took
place instead of an iterative convergence. After cor-recting the period to a comma, the results were
correct to the expected accuracy.
The bug was detected in time and never caused a Mercury space flight to fail as many versions claim
(a different bug, in the Mariner flights, described at the end of the chapter, did have this effect), but it
does graphically illustrate the importance of language design. C has all-too-many similar ambiguities
or near-ambiguities. This chapter describes a representative sample of the most common ones, and
how they typically show up as bugs. There are other problems that can arise in C; for example, any
time you encounter the string malloc(strlen(str)); it is almost always sure to be an error,
where malloc(strlen(str)+1); was meant. This is because almost all the other string-
handling routines include the room needed for the trailing nul terminator, so people get used to not
making the special provision for it that strlen needs. The malloc example is an error in the
programmer 's knowledge of a library routine, whereas this chapter concentrates on problematic areas
in C itself, rather than the programmer 's use of it.