Recent postings have concerned testing software–therefore, how can we test trek? A goal is good to have, as that may influence what we test and how we go about it. Say we want to modernize the source code,
>
```
int main(argc, argv)
int argc;
char **argv;
{
int ch;
...
```
perhaps on account of it using rather old C that modern C compilers might eventually come to hate. A code refactor may break the game in various ways; whether the code still compiles is a test, but may not catch the logic bugs we may introduce: sorting a list the wrong way, doubling damage numbers, things like that.
“Trek [1]”
The post is briefly about testing the old game Star Trek that was popular in the 70s, and in this case, it's been ported to C probably sometime in the 80s. The game is interactive so writing any form of tests (much less “unit tests”) will be challenging, to say the least. (the post does go on to say that possibly using expect [2] would probably be in order).
I have a bit of experience here with older C code. At one point, I got interested in Viola [3], an early graphical web browser from 1992, and is the type of C code that gives C a bad name. It was written in a transition period between K&R (Brian Kernighan and Dennis Ritchie) C and ANSI (American National Standards Institute) C, so it had to cater to both, so function prototypes were spotty at best. It also made several horrible assumptions about primitive data types—mainly that pointers, integers and long integers were all interchangable, and plenty of cases where signed quantities were compared to unsigned quantities.
Horrible stuff.
The first thing I did was rewrite the Makefile to simplify it. The original build system was a mess of scripts and over 7,000 lines of make across 48 files; I was able to get it down to just 50 lines of make in one file. Of course, I'm only interested in getting this to compile on POSIX (Portable Operating System Interface) systems with X Windows [4], so it's easy to simplify the build system.
Second step—crank the C compiler warnings to 11, and fix all the warnings. That's when I started finding all the buried bodies—longs and pointers interchanging, questionable casts, signed and unsigned comparisons and much much more. I got it to the point where it works on a 32-bit system, and it compiles on a 64-bit system but promptly crashes. And by “works” I mean, I can browse gopher with it, but trying to surf the modern web is laughably disasterous.
But I digress—the first is to crank the compiler warnings to 11 and fix all the warnings, then convert K&R C function declarations to ANSI C.
Does that count as “refactoring?” I personally don't think so—it's just mechanical changes and maybe fixing a few declarations from plain int to unsigned int (or size_t). And once that is done, then you can think about refactoring the code.
[1] gemini://thrig.me/blog/2022/12/24/trek.gmi
[2] http://tcl.tk/man/expect5.31/expect.1.html
[3] https://en.wikipedia.org/wiki/ViolaWWW
Interesting articles on the C programming language