Old C code – how to upgrade it?

Probably do the same thing that the Linux Kernel did when it wanted to move to a newer version of C.[0] Make the change, see what breaks.

[0] https://lwn.net/Articles/885941/

     *(--(char*)hash_ptr.parm.v.p) = fpop(sst);

  char *p;

  p = --(char*)hash_ptr.parm.v.p;
  *p = fpop(sst);

You forgot to link to your efforts from 2 years ago: https://github.com/mikewarot/stoical

What sort of "horrible death"? Do you have a dump? As Admiral below said.. you will likely just need to make the changes then hack away at the problems one-by-one.

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.

> It's a Forth variant that does typing, and lots of things that normal forth can't do

congratulations ! like a pop song you cannot get out your head, you have found and bonded with something rare, special and worthy.. but like an old, old automobile from your Uncle's backyard, it might take endless efforts for modest (or worse) rewards

> make install and it works perfectly... under Debian 3

you have your first target.. make a VirtualBox VM with Debian 3, install your target software, and guard it well !! backups, small environment improvements.. connection to the Internet even?! small steps are called for..

> Anything newer, even with -std=c99, and it dies a horrible death

standard C99 is not a terrible thing.. the libraries that are linked are the big weakness there, but despite lots of complaining from modern coders, the libraries actually do work for you know, your own use.. thats what you are building, something for one person to use, you!

> I, a non-C programmer, who is willing to dump tons of time into it, migrate this code into the year 2022

you already know the answer to this.. there is no way to port C code to standard C99 without knowing C. So, you have to cooperate with others somehow. This post is not a bad start, but if you are looking for volunteers, there has to be benefit for them. A random other person who also finds this obsessively compelling.. probably not a realistic outcome, even with the massive audience at YNews. There are legions of middle-aged guys who know C at the C99 level, but for whatever reason are not professionally programming right now. This might be a local search, in "meat space" or, alternatively worded invites, in other forums or mailing lists. Good luck!

Basically, "dump tons of time" will probably involve some aspect of becoming a C programmer.

The program has some kind of portability bug or bugs that make it sensitive to the compiler. That the old executable works probably means that it's not a library or environment issue, though that can't be ruled out 100% because an executable from Debian 3 may be using compatibility functions in glibc that a Debian 11 executable wouldn't use.

A C programmer would just debug this on that platform where the problem reproduces.

There are tools which can help pinpoint the origins of behavior that leads to a crash.

- compiling the code with the "undefined behavior sanitizer a.k.a. ubsan" using -fsanitize=undefined.

- compiling the code also with the "address sanitizer (asan)" using -fsanitize=address.

- using valgrind on it

Of course you have the debugger gdb, and the printf function.

Interestingly, the project isn't using optimization (-O0 is specified in the CFLAGS of the root Makefile) so the failure is likely not coming from that class of issue whereby clever optimization defeats the programmer's incorrectly expressed intent.

Perhaps not the answer you're looking for, but look for another library or a re-implementation of it.

> Anything newer, even with -std=c99, and it dies a horrible death.

Yes because the compiler is catching loads of undefined behavior that the code employs. I wouldn't suggest using this library and depending on what it does I'd just suggest finding a newer, more up to date library. Using it as-is probably worked for gcc at the time but it's anyone's guess as to how it'll run today.

If you don't care about any of this, just keep turning off warnings (`-Wno-unsequenced`) until it compiles correctly.

> it dies a horrible death

The answer depends on the exact meaning of that quote.

You could do a binary search on Debian 3 - start upgrading components of the toolchain until it breaks, and then play around with whatever you upgraded.

Likely there's a version of GCC where it works, and one where it doesn't, or the equivalent for a library.

Getting the latest GCC to build on Debian 3 might be an adventure in itself, of course.

I've got a similar issue: I still have my own source code from a cool little DOS game from 1991 or so (running at 50 or 60 Hz, don't remember which: but in any case it was hard stuff for the times). It's a mix of C and some assembly but... I don't have the tooling anymore and, heck, have no memory whatsoever as to which compiler I was using back then. I still have some .exe and they run fine under DOSBox (for example).

I don't know if my best bet is to start from another project that works/compiles/run and then port my old code to that or if I should first try to compile it again.

I was "wise" enough to backup all my code and assets (gfx, music, sound fx) and executables, but foolish enough to not backup the tooling. I never thought that 30 years+ later I'd like to compile it again.

I make several porting projects, regularly as my job in this decades (including learning new language along it), so some tips, adjusting for the fact this is C (auch!):

- Learn well a modern lang (Rust, Zig, Modern C?, ... lets call it the porting LANG).

If you are not a OLD HAT C developer and was "raised" in more modern things, going straight to some modern alternative to C (Rust, Zig, ...) could pay off much more if you are really for the long term.

This not replace the fact you need to know enough C to learn this, but is for your sanity long term (You can disregard this if plan to be a C developer for long).

Is important because:

- Collect a list of requirements and dependencies. C requiere to recreate a lot of basic stuff (like hash, strings, etc).

You can certainly throw all of that. Even if that implementation has some useful property, you don't need that burden (re-implement that) right know.

Modern langs also have better idioms to use memory (no manual mallocs!) and that is another burden that is not worth long term.

p.d: For what I see, this project has TOO BIG of a "re-creating basic stuff that any sane lang has in their std library" than actual code for make the idea work. So spend time there is lost time, IMHO). If stay on C, look for already-implemented alternatives that let you focus in the main tasks.

- Eliminate/Simplify your tooling. If CMake sucks, it sucks. Replace it with the most sane alternative for your LANG.

- Prepare yourself for quickly and merciless refactoring all, all the time. The faster you get in the cycle of "attempt understand, implement, test, rewrite, restart" the better.

All the above is to improve your velocity at the start or in the long term.

In no particular order:

- Put a debugger. Step in the code.

- If you manage to compile the old code, and knowing this is a lang, you have a good chance to make this great for testing: Input STDIN and output STDOUT and use that to confirm things!

- Collect a "call tree" using any means (notes, a tree editor, etc).

Implement things in a new blank project, and write the functions. Be sure you understand the small steps. When stuck, create another mini project and try to pull the idea alone.

This is harder than "just move forward" but the point is that you need to understand the project, not just make it compile, right?

- DO NOT punish yourself if the porting is not 100% exact.

Is more important to match "outcomes" than "exact outputs". Is very likely that you hit a bug or a hack and recreating that stuff is not worth in this case, IMHO.

- Ask things to the community! Go into a good place where discuss stuff for your LANG and ask for help. Also, you can consider go into places like https://www.reddit.com/r/ProgrammingLanguages/ for META questions about language development & paradigms.

P.D: Consider this ideas as not replacements for the others in this thread, just extra things to consider!

There are likely problems with the code even under Debian3 too if it won't build on more modern toolchains.

First is make some simple test case scripts that work on Debian 3, so you can cheaply get a feel for if it still works once it's building again. Run these after evety build.

You might want to run it under valgrind on Debian 3 and fix any bugs coming up there before trying to clean it on a modern toolchain. Because it will be much easier to find and fix those when it runs well and you don't have to guess if the problem is the newer toolchain.

You might want to crank up the compiler warnings step by step on Debian 3 first, and fix those first.

Then bring the cleaned and still working code to a new toolchain, under valgrind.

Don't worry if there are pages of compile errors... these are usually a handful of things wrong appearing in multiple places.

I recommend 2 things 1 statically analyzer,Lint etc This will takeout in advance some problems in the migration 2 maybe create part of the toolchain for the migration, some of the new compilers are modulars and can make the c99 to c11 transition easier, if you don't want to re-implement the code by hand (wich is always a option)

https://m.youtube.com/watch?v=_cIVa-RctcA&t=325s

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)

[1] https://github.com/pflanze/lilyvm [2] https://github.com/pflanze/copycat

I don’t blame you for having a hard time, as that snippet you’re showing is not legal C (you can’t assign to a cast). --(char*)x is not legal C. Old compilers were more permissive though. unfortunately, you are going to have to both become a proficient C programmer and then figure out what the intent of that code was and rewrite it to legal constructs.

  (char*)hash_ptr.parm.v.p = (char*)hash_ptr.parm.v.p - 1; // move the pointer back by one byte
  *((char*)hash_ptr.parm.v.p) = fpop(sst); //At the memory location, write the output of fpop(sst)

    (char*)hash_ptr.parm.v.p = (char*)hash_ptr.parm.v.p - 1;

   --(char*)hash_ptr.parm.v.p

Actually why do you want to move to c99? Shouldnt the goal be that it just compiles on current compiler? Why not solve that first?

What's the exact error code?

Use the -m32 flag when compiling.

There's no way around learning C if you really want to take this on. You said you're willing to dump lots of time in it, so do that first, and then you'll be in a much better position.

> How do I, a non-C programmer, who is willing to dump tons of time into it, migrate this code into the year 2022?

Unfortunately, I suspect the answer is going to strongly involve dumping time into becoming a C programmer. (I say this as someone in a somewhat similar situation; I had no intention of learning C, but I wanted to get into dev work on existing unix-family OSs, which are pretty much all written in C, so guess what I'm learning?)

Thanks so much for all the help.

Backstory - About a week ago, I got the original compiled, learning about autoconf and make a bit along the way. I turned on ALL of the debugging options to try to figure it out.

Stoical is a variant of Forth from BEFORE Fig-Forth, so I didn't even realize it was working at first. It uses = to print, not . which took a while to figure out. Once the penny dropped, and I had it working, I was able to turn debugging back off and find that it works pretty much out of the box. I replicated it on a new Debian 3 VM and it does indeed do so.

Unfortunately, GIT doesn't come with Debian 3, and my attempts to compile it ran into far too many prerequisites, including zlib, Tcl/TK, autoconf (which requires m4, but a newer m4), eventually I quit that approach.

How it works:

There's a small set of built-in words, which it then uses to bootstrap an interpreter (14 words long) which then loads in the rest of the language. All of this works right out of the box in Debian 3. The executable compiled under Debian 11 starts to run, but can't bootstrap itself. Interestingly, the image compiled under Debian 3 does work in it's place.

There's noting exceptional about the example really; the inner * is a cast to string (or char pointer), and the outer is a de-reference to set the value at the specified address (which for unknown reasons is 1 byte before hash_ptr.parm.v.p) to whatever fpop(sst) returns.

Writing interpreters in C is a solid path to really learning the language from my experience, but jumping head first into a code base like that without knowing C is a recipe for frustration and suffering.

There are a million more or less advanced, custom Forths out there; here are some of my own implemented in various languages:

https://github.com/codr7/ampl

https://github.com/codr7/snabel

https://github.com/codr7/alang

https://github.com/codr7/gfoo

https://github.com/codr7/forthy2

I don't understand what "migrate this code into the year 2022" means. What's the actual problem you're trying to solve? If:

    wget, unzip, untar, ./configure, make, su make install and it works perfectly

Then, you're done, right? Why do you need to make any changes? If it doesn't like -std=c99, and it works without it, just don't compile it with -std=c99.

Are you trying to port it to some other host or architecture? If so, you'll need to learn C to port it.

Are you trying to port it to a 64-bit target or something like that? If so, you'll need to learn some C.

Does the existing code compile and run but has show-stopper bugs for you? If so, you'll need to learn C and fix them.