[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.

[rhn_mk1]

I'm not sure how much this helps, but better fire up your Debian 3 inside a virtual machine. Then you can copy files with scp and commit them to git or whatever other version control on your main host.

And those flags should be used first on the Debian 3 machine, at least those which are supported there.

In my experience, jumping straight to the new version and making it "hold its nose" only ever works if you already know what you're doing.

[pjungwir]

With vagrant, the guest's /vagrant directory is whatever host directory contains the Vagrantfile. Using that seems even easier than scp. You can also set up some other shared folder if you're less lazy than me.

[rhn_mk1]

Note that this may detect a lot of problems that are not necessarily fatal. It's just that enabling those warnings and sticking to it prevents errors from appearing once you earnestly start working with the code - like you will need to in order to modernize it.

[all2]

If you use Docker/vagrant you should be able to do your editing/version control on the host machine and handle only compilation on the VM.

[avar]

What problems are you running into getting git on debian 3?

[mikewarot]

I tried installing git... it turns out that in Debian 3 git is the Gnu Interactive Tool, not a source code management program ;-)

So I downloaded the latest version of git source, using wget from

https://mirrors.edge.kernel.org/pub/software/scm/git/git-2.9...

Then I found I needed zlib, from

https://www.zlib.net/zlib-1.2.12.tar.xz

And I also needed Tcl/Tk

https://prdownloads.sourceforge.net/tcl/tcl8.6.12-src.tar.gz

And I also needed autoconf

http://ftp.gnu.org/gnu/autoconf/autoconf-2.71.tar.gz

Autoconf needed a newer version of m4

http://ftp.gnu.org/gnu/m4/m4-1.4.19.tar.gz

m4 couldn't install... I'm not sure why... so I gave up at that point. 8(

[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.