gen-c, a clone of zompist's gen in C, made by me!

[koh]

About a week ago I was like "hmm... I like gen a lot. what if i re-coded it in C for the command line".
And the rest is history. History that you can personally check out if you want, since the project is hosted on codeberg, a git forge, therefore you can look at past stages of the project.
Here it is!! -> https://codeberg.org/koh/gen-c

I'm finally making this post because I just released version 1.2, which has Unicode support, meaning that it works with IPA symbols, Emojis, Chinese Han script, Chess pieces, whatever your heart desires! The program is now at a stage when I think I'm ready to share it here, as per Zompist's suggestion.

There've been lots of ups and downs working on this project, like for example how I decided to start this project after not working with C strings or C in general in a while, and not really remembering how the stack vs the heap worked, so, at the beginning, instead of using char []s (character arrays) with an allocated size on the stack, I was using (unallocated) char *s (character pointers) and was wondering why my simple snippet of code which only reads text from a file doesn't work, lmao.
That was a bit demoralizing. But we persevere.

Another big challenge was implementing Unicode support, which is pretty important for, you know, a program which most people would probably use with IPA symbols and such.
I went down the wchar.h rabbithole before learning that the wchar_t type is mostly useless and I can just store code points in 32 bit integers, after converting them from utf-8 to utf-32.
I then went on a hotstreak of creating utf-32 helper fuctions for string manipulation (strlen -> utf32strlen; strncmp -> utf32strncmp) but did minimal testing on them and proceeded to add them ALL AT ONCE to the code, instead of checking one thing at a time, resulting in one mess of a codebase, and a few overwhelming hours of debugging. But we persevere.
I reverted those changes and started again, this time implementing one utf-32 function at a time and fixing what was wrong. And now here we are!

Currently, there is a gen-c v1.2 x86_64 Linux release, and you can download the executable from the codeberg repository I linked near the top, on the releases tab.

Now - gen-c is free software (AGPLv3.0), so, of course, you can inspect the code yourself and compile it on your own machine, if you don't trust the executable I uploaded. Since it's free software, it also means you can fork it and modify it to your liking, study it, and freely redistribute it, as long as the AGPLv3.0 licence is also redistributed with it, giving the same rights that are given to you by the license to everyone else you plan to distribute the program to.
See the actual AGPLv3.0 license for more info, as my clumsy explanation won't suffice to fill you in on the details.

[Raphael]

Does anyone who, unlike me, knows enough about the subjects involved to really evaluate this thing, have any comments?

[Travis B.]

I have one suggestion ─ provide an option to, instead of using /dev/urandom as a randomness source, allow the user to explicitly specify a seed for a pseudorandom number generator, thus allowing repeatability when so desired, and when that option is not selected use /dev/urandom just to select said seed, and output said seed to the user allowing them to repeat it if they so wish.

[koh]

[...] instead of using /dev/urandom as a randomness source, allow the user to explicitly specify a seed for a pseudorandom number generator, thus allowing repeatability when so desired [...] when that option is not selected use /dev/urandom just to select said seed, and output said seed to the user [...]

This is a very good suggestion!
I've been thinking of overhauling the randomness system now and again. I don't know why I didn't think of this myself tbh. In hindsight it seems obvious. The user should have more control over the seed.
The program already uses a PRNG - splitmix64 - which is not cryptographically secure but is cheap and very fast.

[koh]

Implemented it!
You can see the seed the program uses every time it runs and you can specify which seed to use through the -S flag (optionally -seed).
Thanks again for the feedback

[Raphael]

That was fast!

[koh]

yupp! since splitmix64 was already implemented, i just added some logic to check for a user-given seed and voila!
what isn't fast is this reply i'm writing lmaoo
i just now saw there's a new post in the topic

anyways,
I might make some more changes and soon publish an v1.3 release
in any case, I made git track the executable in the repo, so, every time i commit changes, the executable gets updated - so anyone can download the latest in-development exe too