[fundamental]

Taking a quick look at the source it doesn't look too bad all things considered. First off, assume that there's going to be some sort of 32bit->64bit issues (likely casting pointers into 32bit words). So, start off on a 32bit setup, get things to cleanly build on -std=gnu99 (no need to cause yourself extra pain if it's optional). Then tidy things up with warnings (-Wall -Wextra on clang&gcc) such that the compiler can help you spot any existing bugs. Next up is the transition to 64bit. You're likely going to have to spot any pointer manipulation and where possible change 'int', 'long', etc into types which specify their length to make reading the code easier (subjective, but that's my opinion) e.g. uint32_t, uint64_t, etc. Then you ought to be pretty close to having all system tests pass on 32bit and the 64bit port.

I'd be worried if the code was old enough you were seeing K&R C notation or if it was a huge codebase, but it doesn't look like either case has occurred.

Of course if you're very much not a C programmer, learn some C. It's a comparatively small language overall (IMO) even if it's a low level one. Newer versions of the K&R book should get you up to speed pretty quick.

[rhn_mk1]

Here's a set of C compiler flags that I find especially useful to prevent bugs from occurring:

-Werror=implicit-function-declaration -Werror=implicit-fallthrough=3 -Werror=maybe-uninitialized -Werror=missing-field-initializers -Werror=incompatible-pointer-types -Werror=int-conversion -Werror=redundant-decls -Werror=parentheses -Wformat-nonliteral -Wformat-security -Wformat -Winit-self -Wmaybe-uninitialized -Wold-style-definition -Wredundant-decls -Wstrict-prototypes

[creativemonkeys]

on small projects, with clang, I use "-Weverything -Werror" and then I start fixing the issues one by one. I also either disable anything I'm willing to live with using -Wno<warning> or I use '#pragma clang diagnostic ignored "-W<warning>"' if it's only relevant for specific portions of the code.

[mikewarot]

I'll be trying that magic incantation shortly.

[Edit] I tried it, and it didn't make anything worse.

What I was hoping to find (and spend a few days looking) was for some set of flags I could give to a modern copy of gcc to hold it's nose and compile this code as-is, as a starting point.

Git under Debian 3 seems to be a no-go. I'm tempted to just have two virtual machines that are never on at the same time mount a separate virtual disk that holds the Stoical source code and git repository.

Make changes / test in Debian 3... when happy shut it down, fire up Debian 11 and do a commit and push to github. Shut it down, fire up Debian 3, repeat.

[hermitdev]

Yes! Was going to suggest much the same: crank up the warnings and treat them as errors!

[andrewf]

I'll second the suggestion to attack one problem at a time. A very long time ago I was on a team that built a desktop application in Qt + Visual C++ for Windows (98/ME/2K/XP), and we wanted to port it to Mac OS X (10.3) on PowerPC.

First, we addressed the compiler issue, getting it to build with GCC instead of VC++ on Windows. This was the most time-consuming step.

Second, we built on Linux x86 with GCC, because we were quite familiar with it, and this enabled..

Third, we built on Linux PowerPC with gcc, which was the little -> big endian step.

Finally, we got it running on OS X.

For your issue in particular, I'd try to stick with 32-bit x86 over x86-64 to start, and inch my way through newer Debian and gcc versions. You could install gcc-4.2 as late as Debian 5, I think.

[pm215]

The code is doing a lot of preprocessor macro magic, though, which rather obscures some of what is going on.

[pflanze]

Macro-expanding the files via the -E option (and then passing the result through clang-format) can help in these cases.