pretzelhammer / brainfuck_compilers Goto Github PK

Different brainfuck programs handle EOF differently. Some expect EOF to be stored as 0, some expect it to be stored as -1, some expect it to not be stored as any value, i.e. not modify the current byte at the pointer in any way, and some ignore the possibility of EOFs entirely. Unfortunately we have several of these programs in our test collection, so I think it's worth it to note the differences in their behavior here in case I ever want to potentially fix these discrepancies in the future. The interactive programs in our test collection are: guess_number.b, head.b, rot13.b, tic_tac_toe.b.

guess_number.b

Ignores EOF characters. Works okay when interpreted or compiled to x86_64, aarch64, or wasm32-wasi but the LLVM IR version goes into an infinite loop because the libc getchar() function caches EOF responses and returns them immediately without subsequently querying stdin so the brainfuck program enters an infinite loop.

rot13.b

This program expects EOF to be 0 or no-change and works consistently across the interpreter and all compilers.

head.b

This program expects EOF to be no-change and immediately exits in the x86_64, aarch64, and wasm32-wasi compiled versions on EOFs, ignores the EOF character in the interpreted version, and enters an infinite loop in the LLVM IR compiled version.

tic_tac_toe.b

Ignores EOF characters. Has the same problem as guess_number.b, LLVM IR compiled version goes into infinite loop.

How to fix

I think I could fix all these discrepancies by first changing the semantics of the interpreter/compilers to treat EOF as a no-change instead of as 0. Second, for the interpreter and LLVM IR compiler specifically, I could keep track of if I've ever read an EOF before and if the brainfuck program tries to , again after it already received an EOF then I can just make exit it immediately, avoiding any weird behavior or infinite loops due to the program not handling EOFs. The problem with the above 2 fixes is that it makes the codegen for the , command kinda ugly and it's also boring and tedious to have to explain these dumb edge cases in the article. I'm gonna hold off on making any changes or fixes to the code for now, and I'll leave this issue here as documentation for the genuinely curious and engaged readers to find.