| 1 | Here are some little programs for testing brainfuck implementations.
|
|---|
| 2 |
|
|---|
| 3 |
|
|---|
| 4 | >,>+++++++++,>+++++++++++[<++++++<++++++<+>>>-]<<.>.<<-.>.>.<<.
|
|---|
| 5 | This is for testing i/o; give it a return followed by an EOF. (Try it both
|
|---|
| 6 | with file input--a file consisting only of one blank line--and with
|
|---|
| 7 | keyboard input, i.e. hit return and then ctrl-d (Unix) or ctrl-z
|
|---|
| 8 | (Windows).)
|
|---|
| 9 | It should give two lines of output; the two lines should be identical, and
|
|---|
| 10 | should be lined up one over the other. If that doesn't happen, ten is not
|
|---|
| 11 | coming through as newline on output.
|
|---|
| 12 | The content of the lines tells how input is being processed; each line
|
|---|
| 13 | should be two uppercase letters.
|
|---|
| 14 | Anything with O in it means newline is not coming through as ten on input.
|
|---|
| 15 | LK means newline input is working fine, and EOF leaves the cell unchanged
|
|---|
| 16 | (which I recommend).
|
|---|
| 17 | LB means newline input is working fine, and EOF translates as 0.
|
|---|
| 18 | LA means newline input is working fine, and EOF translates as -1.
|
|---|
| 19 | Anything else is fairly unexpected.
|
|---|
| 20 |
|
|---|
| 21 |
|
|---|
| 22 | ++++[>++++++<-]>[>+++++>+++++++<<-]>>++++<[[>[[>>+<<-]<]>>>-]>-[>+>+<<-]>]
|
|---|
| 23 | +++++[>+++++++<<++>-]>.<<.
|
|---|
| 24 | Goes to cell 30000 and reports from there with a #. (Verifies that the
|
|---|
| 25 | array is big enough.)
|
|---|
| 26 |
|
|---|
| 27 |
|
|---|
| 28 | These next two test the array bounds checking. Bounds checking is not
|
|---|
| 29 | essential, and in a high-level implementation it is likely to introduce
|
|---|
| 30 | extra overhead. In a low-level implementation you can get bounds checking
|
|---|
| 31 | for free by using the OS's own memory protections; this is the best
|
|---|
| 32 | solution, which may require making the array size a multiple of the page
|
|---|
| 33 | size.
|
|---|
| 34 | Anyway. These two programs measure the "real" size of the array, in some
|
|---|
| 35 | sense, in cells left and right of the initial cell respectively. They
|
|---|
| 36 | output the result in unary; the easiest thing is to direct them to a file
|
|---|
| 37 | and measure its size, or (on Unix) pipe the output to wc. If bounds
|
|---|
| 38 | checking is present and working, the left should measure 0 and the right
|
|---|
| 39 | should be the array size minus one.
|
|---|
| 40 | +[<+++++++++++++++++++++++++++++++++.]
|
|---|
| 41 |
|
|---|
| 42 | +[>+++++++++++++++++++++++++++++++++.]
|
|---|
| 43 |
|
|---|
| 44 |
|
|---|
| 45 | []++++++++++[>++++++++++++++++++>+++++++>+<<<-]A;?@![#>>+<<]>[>++<[-]]>.>.
|
|---|
| 46 | Tests for several obscure problems. Should output an H.
|
|---|
| 47 |
|
|---|
| 48 |
|
|---|
| 49 | +++++[>+++++++>++<<-]>.>.[
|
|---|
| 50 | Should ideally give error message "unmatched [" or the like, and not give
|
|---|
| 51 | any output. Not essential.
|
|---|
| 52 |
|
|---|
| 53 | +++++[>+++++++>++<<-]>.>.][
|
|---|
| 54 | Should ideally give error message "unmatched ]" or the like, and not give
|
|---|
| 55 | any output. Not essential.
|
|---|
| 56 |
|
|---|
| 57 |
|
|---|
| 58 | My pathological program rot13.b is good for testing the response to deep
|
|---|
| 59 | brackets; the input "~mlk zyx" should produce the output "~zyx mlk".
|
|---|
| 60 |
|
|---|
| 61 |
|
|---|
| 62 | For an overall stress test, and also to check whether the output is
|
|---|
| 63 | monospaced as it ideally should be, I would use Linus Akesson's game of
|
|---|
| 64 | life and/or my numwarp.b.
|
|---|
| 65 |
|
|---|
| 66 |
|
|---|
| 67 | Daniel B Cristofani (cristofdathevanetdotcom)
|
|---|
| 68 | http://www.hevanet.com/cristofd/brainfuck/
|
|---|
