malbolge | A Malbolge implementation and interpreter in Rust | Interpreter library

I've been stepping through the Malbolge interpreter in a debugger in order to diagnose what's going on here. I would say "congratulations, you've discovered a bug in the Malbolge interpreter", but given that the spec and interpreter don't match each other in other ways (with the authoritative version normally taken as being the interpreter), and that this is Malbolge, for all I know this is intended behaviour. (OK, it probably isn't actually intended behaviour, but then neither are a number of other features that have come to be treated as important programming techniques.)

Malbolge stores everything in one big array, both code and data. Commands are intended to modify ("encrypt", in Malbolge terminology) themselves after running, but the interpreter didn't quite end up implementing that correctly: what it actually does is to run a command, then look at the address pointed to by the code pointer and encrypt that. That's why jumping will encrypt the instruction before the jump target, rather than the jump instruction itself.

If the command that you're running is outside the range 33 to 126 inclusive, the command isn't run (actually, in the version of the Malbolge interpreter I have, the code and data pointers aren't increased either, which seems like it would inevitably lead to an infinite loop; perhaps there are other versions around which fix that issue). That's an important check because the encryption routine simply works by indexing into a lookup table; values outside the 33 to 126 range will end up reading some arbitrary byte of memory from before or after the array.

Unfortunately, because the code and data are stored together in one big array, a command can end up modifying itself as it runs: it might have been in the 33 to 126 range before running (thus causing the safety check to succeed), but after running, it's out of range and then the encryption will end up doing an out-of-bounds index of the lookup table. The Malbolge interpreter is written in C, which has undefined behaviour for out-of-bounds reads, but for reads that are a very long way out of bounds, a segmentation fault is likely (but not guaranteed) behaviour.

Let's look at what happens with the code u&a: