I've been coding some 10-15% of my two-decade coding career in C (and C++), and have been mentoring people over video conferencing and a shared server accessed via VNC. Usually I do that for pay, but I'm interested in programming language implementations (I'm doing some of that myself)[1], and I've occasionally been working on implementing a Forth-like language myself[2], and so I'm willing to spend some time with you (say, 10 sessions, ~2 hours each) for free. Let's see what we can achieve, and I'll tell you at any point what the best way forward will be. I don't really share the opinion with some others who suggest to re-implement it in another language--for that you really have to understand the original code base first, and if you do, then it shouldn't be hard to fix the issues in C, either. I personally will probably suggest to leave it in C, it will most likely be less work, and it will have lighter dependencies. You can find my contact info from my profile.
PS. some of the first things to do will be to:
- if there's a way to get hold of previous versions, make a fresh Git history that includes them, so that the changes can be correlated with release notes
- use the sanitizers offered by today's compilers, or valgrind if having to compile it with old compilers.
- read the code about how it encodes pointers, and adapt that to 64 bit if needed
- maybe instrument the garbage collector if issues show up there, maybe move to allocating memory via malloc so that the memory sanitizer will catch violations
- write documentation about the workings that we study (that helps getting a clear mind and staying focused, and may help people in the future)
- Write lots of tests with high test coverage before migration. Then you can rely on them on a continuous basis to make sure any updates do not break the existing functionality
Yes, extending the test suite may definitely be worthwhile. Also, using AFL+ to collect non-crashing test cases can make this quick and somewhat exhaustive (while admittedly not giving as easy hints about what might be broken than manually created tests would).
OK, I'm fine with opening it up, too, and we should probably so so, that may give more input. There have been lots of fixes posted already, and I haven't checked whether that solves everything (this would be a bit counter to helping in a natural way), so I don't know whether there's actually anything left to do. For either case, I've put up a page which will contain updates on the events here[1].
Public live streaming is new to me and so far I've evaded any public records of my video and voice, maybe that's pointless since this will become increasingly impossible into the future, but I'm undecided and so far am planning for conference calls that, while open for anyone to join (see [1]), will not make recordings public. I might be swayed. I'm also still not omniscient in the C world (the most glaring is probably that I've never used the GNU autotools!), OTOH I'm yearning for somewhat higher levels of abstraction so my C coding is often untypical, so YMMV if you're after learning standard ways of working in C.
My concern with the current setup is that I am in GMT+10 timezone. This means that some 'livestream' events are not able to be viewed due to work or life commitsments. I will keep an eye on this topic though.
I noticed some people working on an LLVM backend for the 6502; I may revisit the C-64 target once that matures (it will generate better code than cc65, and I'm now relying on modern C features that cc65 doesn't support). I currently concentrate on getting LilyVM to do anything useful for me on modern systems. (I've got some more work that I haven't pushed yet; but I mainly need to finally start working on the compiler to bytecode, which is a larger can of worms than the VM. I might first re-implement Copycat on it.)
I'll be up to help. I've been programming in C for 30 years now (and still do). One of my "when I'm bored" projects is updating an early 90s C code base [1]. And I do have an interest in Forth, so this sounds like an interesting project. My email is on my profile.
[1] Viola, one of the first graphical web browsers that assumes sizeof(int) == sizeof(long) == sizeof(every pointer).
PS. some of the first things to do will be to:
- if there's a way to get hold of previous versions, make a fresh Git history that includes them, so that the changes can be correlated with release notes
- use the sanitizers offered by today's compilers, or valgrind if having to compile it with old compilers.
- read the code about how it encodes pointers, and adapt that to 64 bit if needed
- maybe instrument the garbage collector if issues show up there, maybe move to allocating memory via malloc so that the memory sanitizer will catch violations
- write documentation about the workings that we study (that helps getting a clear mind and staying focused, and may help people in the future)
[1] https://github.com/pflanze/lilyvm [2] https://github.com/pflanze/copycat