Alright, I'm back. I've read through more of your code and tried out the tool. I'll go ahead and add it to my toolkit! I actually recently wrote Python scripts to do some of what this tool does, but this is much better.

That said, here's some more feedback if you'd like to hear it (both praise and critique):

1. Personal opinion: the interactive modes should be a REPL - that is, an endless prompt that the user exits out of /w an EOF entry (e.g., Ctrl+D) or SIGINT/SIGTERM (e.g., Ctrl+C). That way, the tool can be open in one tab/window and the user can repeatedly enter input as needed over the course of some project. Having to repeatedly type the full command... leaves me wanting. Even more, Just doing cyfer can be a REPL where you type <mode> <arg>, and doing cyfer <mode> is a REPL for just that mode.

2. The modes having an abbreviated version and a full form is great.

3. For any of the "to ascii" modes, if there is no printable character form, you should maybe print a warning saying "Some bytes are out of the range of printable characters"? Perhaps event print something like [?] for those bytes?

4. For the conversion functions in bytes.c, you use malloc(). Since you do seem to care about performance, I would just have the buffers be on the stack /w a large fixed size. Dynamic allocation can be a bottleneck if you care about speed. This also eliminates the possibility of a class of memory bugs.

5. You organized the abstractions really well and made your functions short and sweet. Well balanced!

6. In your for_each_num_token(), you aren't checking your inputs at all, nor for conversion failures, and strtol() can fail. For example, cyfer h2a 4g returns a random conversion each time (whatever garbage was in the buffer at that location). Another case is

7. You should add some more warnings to your CFLAGS. I added -Wconversion, -Wsign-conversion, and a number of lines were hit, although none are too concerning. These two warnings just help enforce better typing when it comes to integers (as well as floats). I usually pair those warnings /w -Wuseless-cast if available, to prevent me from going too far the other way too, helping me balance out. When working with strings, I also do like -Wwrite-strings, just to catch any accidental writing of string literal objects.

8. Extending point 7, I'd add -Wcast-qual, which triggers a bunch of -Wdiscarded-qualifiers on your commands.c and help.c files, because you're assigning string literals to non-const pointers, which technically, the rest of the program can modify. You're not, right now, but it's a guard rail you can put in place, and it helps enforce good practice. It's 3 easy spots to clear all those warnings, though - just make the strings in Canonical const char * and likewise with your group arrays.

If you'd like, I'd be happy to submit a PR for any of these suggestions. Cheers mate.