Some notes on working with old C code

* * * * *

Some notes on working with old C code

> 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,
>
> -----[ C ]-----
> int main(argc, argv)
> int argc;
> char **argv;
> {
> int ch;
> ...
> -----[ END OF LINE ]-----
>
> 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
[4] https://www.x.org/wiki/
---

Discussions about this page

Interesting articles on the C programming language
https://www.cs.purdue.edu/homes/mcrees/c.shtml

Some notes on working with old C code | Lobsters
https://lobste.rs/s/p3uwyt/some_notes_on_working_with_old_c_code

Email author at [email protected]