Bug fixing and Program Size
Howard Hull
hull at hao.UUCP
Mon Dec 31 03:27:17 AEST 1984
Dick Dunn @opus writes:
>[Interesting side-side issue: You may have heard the quip that "Every
>program has at least one bug and can be shortened by at least one
??? ?? ^^^^^^^^^
>instruction"--from which, by induction, one can deduce that every program
>can be reduced to one instruction which doesn't work. IEFBR14, if written
>as the obvious, single-instruction program " BR 14", does NOT work.
I really like this! Where did you hear it? Only trouble is, it conflicts
with my experience. Usually, when I find a bug,
1. Both decreases and increases in instruction count are likely
by some number, the average being 2.71828182845904523536
The implication is that to avoid bugs, every program to do a
function must be written in every possible way. To be absolutely
sure that you have the solution in the bag, you must write a
program to do everything there is to do, by writing a set of
programs to do each thing. Then all of these programs must work
together.
The probability that they will do this is given by 1/(n factorial)
in each case, where n is the number of ways to do each particular
task. For some of you, the number of tasks, t, approaches infinity.
The result will inescapably include both of the following:
needed functions unnecessary functions
that have been omitted that have been included
Now then, if all of the above are properly combined, you have:
UNITY (There is in each case, after all, always
t only one *right* way to do everything!)
The Result = Sigma _______________________________________
n=0 (n!)
2. The bug will be in a real-time program running under one of
the Unix clones adapted for the purpose. The change in the
program length will wreck something else, either spatially
or temporally.
3. Because the numeric mentioned under [1.] above is greater than
unity, and is also greater than the binary base, the average
(program, data) length will grow (perhaps stochastically) faster
than its intellegent content - in a very familiar way - the number
of bits of address will crawl over the edge of any imaginable page
size definition in a vernier fashion as the program is developed.
4. As a result of bug fixes, a program has some random probability
of either vanishing completely, or of consuming the entire storage
capacity of the machine. Which way it will go depends mostly on
the rounding algorithm used in the (undocumented) arithmetic
subroutines that came with the software, and the (erroneously
documented) algorithm the mainframe manufacture used for the
determination of which instructions will set, clear, or not
molest the carry bit. :-)
{ucbvax!hplabs | allegra!nbires | harpo!seismo } !hao!hull
More information about the Comp.unix
mailing list