According to Wikipedia, the Jargon file defines “bit rot” as a jocular explanation for the degradation of a software program over time even if “nothing has changed”; the idea behind this is almost as if the bits that make up the program were subject to radioactive decay. I’m sure that you have experienced this as I have when a program that has worked perfectly for years suddenly stops working correctly because of decaying bits in the program.
But I have recently been fighting a new level of bit rot where the source code of the program no longer compiles or compiles into a non-functional program. I’m calling this “Meta Bit Rot.” Here are four recent examples I came across when rebuilding some programs for Apple “M” Silicon:
Compiling the 68HCS12 simulator
A user of my 68HCS12 simulator program, itself over 20 years old and written in Java, uncovered an error. Perhaps bit rot, but the error was always there, so might not be considered bit rot in itself. At any rate the error was obscure because hundreds of students over the years used the program without seeing the bug which was part of the built-in disassembler.
The last change to the program was well over a decade ago and I used Borland JBuilder as the IDE and compiler. Borland and JBuilder are both deceased. So I imported the code into Netbeans, fixed, the bug, recompiled and it ran.
I sent the executable to the customer and it didn’t run on his system. So much for build once and run anywhere. As it turns out he was running an old Linux computer and had an old Java runtime. Now Netbeans allows retargeting to older runtimes, but when I tried this the Simulator still wouldn’t work for him, nor would it work for me anymore.
The solution? I pulled an old Mac mini out of my closet which hadn’t been used in a decade, but had an old copy of Netbeans installed. When I compiled on the old computer with the old compiler I got an executable that worked for the customer and also works on my new system.
Programs using gets()
“They” say to never use the C function gets because it is unsafe, however there is plenty of old programs that use it. The most recent C compiler for the Mac now issues a run-time warning/error message for programs that use gets. That’s right, you can compile the program and only get warning, but the program tattles on you to the end user that you used gets.
So I had to find all uses of gets, like “gets(name)” and replace with:
if (fgets(name, sizeof(name), stdin) != NULL) {
name[strcspn(NAME, "\n")] = 0;
}All this to get rid of the runtime message when running programs written 40-50 years ago.
Gfortran and Dungeon
This one was simple. The Fortran-based Dungeon (aka “ZORK”) game now gave hundreds of error messages about something called “BOZ” which turns out to be the way to format binary, octal, or hexadecimal literals. The fix was to add -fallow-invalid-boz to the compiler command line. Apparently at one time invalid BOZ literals were considered OK.
64-bit C longs and packed data in Adventure
This was a first-time compile that failed to run properly. The Adventure Game (aka “Colossal Caves Adventure” dates back to the mid 1970s and was in Fortran. However the copy I have was converted to C in the early 1980’s. Computers had smaller word sizes then and long integers were 32 bits.The original game saved it’s data in an array of long integers and assumed that they were 4 bytes long when packing and unpacking data. When using a modern system with 64-bit longs there would be holes in the array causing a byte-based checksum to fail. I fixed the problem by changing a few “4”s to “sizeof(long)”.
Gotta watch out for aging code!