catseye/befunge-93

MIRROR of https://codeberg.org/catseye/Befunge-93 : The NEW reference distribution for Befunge-93!

befunge-93's Issues

Strange behaviour of & command on invalid input and end-of-file

Not sure if you would consider this a bug, but I've always found it a bit frustrating that when piping input from a file, the & (input integer) command returns an undefined value on end-of-file. You can also get this issue if the user enters a non-numeric value as input.

The source of the problem is the b variable (into which the input is read), which is never initialized before the fscanf call. So if the call fails, the variable is left uninitialized, and the value returned could be anything (on the old DOS interpreter I used to get 65537, but on modern builds, when compiled with stack protection, it can often be a random number).

Note that if a previous instance of the & command has successfully read a value, then the b variable will typically retain that value, so a later read on end-of-file (or invalid input), will just return the previous value that was read.

The fix for this, assuming you consider it a bug, would simply be to initialize the b to some end-of-file/failure indicator before calling fscanf. What value you return is up to you, but one obvious choice is -1 (EOF), which aligns nicely with the behaviour of the ~ (input character) command.

If you do decide to address this issue, note that there is a second variable, used in the debug mode, which would also need to be initialized.

Limits for `p` operation

It is unclear from what I have read what the limits of the p operation are, e.g. this program:

99*:*66p

Does it store 6561 or whatever (signed char)6561 is?

Examples that don't appear to work

While I'm raising issues about the examples, this is something that really frustrated me when I first started learning Befunge. When you try and run these examples, a significant percentage of them don't actually appear to work. There are four broad categories of problems here:

1. Programs that were written before you added warnings in the reference interpreter. So now unless you know to start the interpreter with -i (or in some cases -q), these examples can generate a lot of warnings, in many cases overwhelming the actual output, and making them appear to be broken. This includes: beer4.bf, beer10.bf, befunge1.bf, befunge3.bf, befunge4.bf, befungex.bf, bridgeit.bf, palinqn.bf, and rand13.bf.
2. Programs that include b97 directive headers, which generally just fail outright unless you know to start the interpreter with the -= option. This include: postfix.bf, postfix2.bf, quine.bf, quine2.bf, quine3.bf, and revquine.bf.
3. Programs that are simply just buggy (some more so than others). This includes: beer.bf, befbef.bf, digitalr.bf, easm.bf, numer.bf, rand13.bf, and serp.bf. In a number of cases these already have fixes though (befbef.bf was fixed by befbef2.bf, easm.bf seems to have been fixed by easm2.bf, and serp.bf was fixed by serp2.bf).
4. Programs that have a variety of other problems: pi2.bf (this is Befunge-97 not Befunge-93), switchbx.bf (essentially a snippet of code - not actually runnable by itself), prime.bf and rand12.bf (expect unsigned memory cells, so while partially working, the output isn't what was intended).

Groups 1 and 2 can possibly be addressed by including an indicator of some sort (e.g. something like a footnote marker) just letting people know that they need to run those examples with the required option enabled. Note that in group 1, most will work with either -i or -q, but bridgeit.bf and palinqn.bf must use the -q option.

Group 3 is more of an issue, but I would have thought you could at least get rid of the broken examples when there is a working replacement. And if you think the broken code is worth keeping for historical interest, perhaps you could move those examples into a separate subdirectory? But worst case, some kind of marker in the readme would be better than nothing.

As for the rest, pi2.bf I'd maybe suggest moving to your FBBI example collection, since the code is still forward compatible with Befunge-98. The others I don't know - maybe just mention something in the readme notes again.

All that said, if I were you I'd probably reconsider whether it's worth keeping many of these examples. I mean do you really need 15 random number generators and 10 different versions of "99 bottles of beer"? The good stuff kind of gets drowned out amongst all the repeats.

I/O fails in debug mode when CONSOLE not defined

If bef is compiled without the CONSOLE define, and you try to debug a program which uses any of the input/output commands, the code won't be interpreted correctly. It's not just that the I/O commands aren't supported - the problem is that they leave the stack in the wrong state. The output commands don't pop anything, and the input commands don't push anything.

As a minimal "fix", you could just include a pop for the output commands, and maybe push -1 for the input commands. In case it's not obvious what I mean, here's a possible patch:

nocon-patch-1.txt

If you want to make a bit more effort though, it is possible to get quite close to the conio implementation using just ANSI escape sequences. I've put together a basic patch showing how that could work:

nocon-patch-2.txt

But that's just a proof-of-concept - you can see that there's a lot of code duplication going on which is in desperate need of refactoring. That level of change I think is best left to you, though, assuming you even what to do anything with this issue.

Debugger never leave loops?

I just started playing around with befunge I was playing around with the debugger and noticed that it never leaves a loop, even though the code works.

For example, when running the following code in debug mode, the cursor never reaches the end. Is this an issue with the debugger, or is there something I don't understand.

"E">:# ,# _@

Support compiling on MSVC

I don't know if this is something that you'd necessarily want to support, but when I saw the work you were doing to get bef compiling on different platforms, I thought you might be interested in the patch I use to compile in Microsoft's Visual C (the cl command line compiler).

The only change required in the code was a mapping of the sleep function to Microsoft's _sleep. The bigger issue was getting a working Makefile. I don't believe it's possible to create something that's compatible with both GNU make and Microsoft's nmake, so I just created a completely separate NMakefile (I build with nmake -f NMakefile).

Anyway, if you're interested, I've included the patch below. This is against the develop-2018-1 branch, in case that matters. If you prefer a PR, I could probably do that too.

msvc-patch.txt

Commands misnamed in Appendix A

In the command summary in Appendix A of the documentation, the commands $ . and , have all been labelled as "pop", but I expect the latter two were probably intended to be something like "output value" and "output character".

Not exactly a major issue, since the actual functionality of each command is clearly explained in the final column, but I thought if you're doing a bit of clean up for the Silver Jubilee, this might be something you want to address.

signedness of char

References:

• Befunge-93 cells were not unsigned, contrary to what the Funge-98 specification states.
• Several examples that don't appear to work are due to the fact that they assume the interpreter uses unsigned char for playfield cells.
• When I audited compilability I should have checked what char signedness each of those compilers assumes. I plan to do that as part of this issue, using this program, which appears to do the right thing with gcc and gcc -funsigned-char:

#include <stdio.h>

int main(int argc, char **argv) {
    char a = (char)127;
    char b = (char)127 + (char)1;
    if (a > b) {
        printf("char is signed char\n");
    } else {
        printf("char is unsigned char\n");
    }
    return 0;
}

@j4james If you could check the version of MSVC you used with this too, that would be lovely.

As for what to do about it: I don't plan to do anything officially - at the end of the day, signedness of playfield cells in Befunge-93 is just as undefined as signedness of char in C. It's not a great situation for real software engineering, but this isn't real software engineering (cockamamie is our watchword!) and it's been like this for 25 years so why switch horses now?

In practice, if you have a Befunge-93 program that relies on it, you can test it just like the C program tests it (use ` and branch - in fact I think I'll write a Befunge-93 example program that does just that, to demonstrate). Granted, that uses up precious playfield space, so you can just document that it relies on it instead.

In essence there are two minor variations of the language, "Befunge-93 with signed playfield cells" and "Befunge-93 with unsigned playfield cells", which co-exist. Some programs are polyglots that run the same in either variant. Some aren't.

But I would like to do more research on it, and possibly document it somehow, because if there is a distinct bias towards a particular signedness out in the wild (catseye/Funge-98#2 argues the bias is towards signed), it won't hurt to raise attention to it as a potential de facto standard. This will also help contextualize what some example programs do / are supposed to do, in #20.

audit befprof and bef2c

befprof anf bef2c probably still have the bugs bef used to have with off-by-one errors and such. They should be tested and fixed.

Typos in the documentation

A couple of typos I recently noticed which I thought you might want to patch in the doc-updates branch in case you decide to do something with that in the future.

• In the last paragraph of The Stack section, you have "If the stack is be empty", which I guess is either meant to be "If the stack is empty" or "If the stack should be empty" (which is what it was in the v1.0 docs).

• In the opening paragraph, I believe the word "occassionally" should be spelt "occasionally" (one s).

• In the Self-Modification section, the word "auxilliary" should be spelt "auxiliary" (one l).

Acknowlage the existence of infinite grid interpreters?

Although not strictly compliant to the Befunge 93 spec, there are numerous Befunge interpreters (including mine) that do not include the wrapping feature as they have effectively infinite grids. I'd like to propose a variation on Befunge 93 that acknowledges this fact.

Get GitHub to display the languages used in this repo less incorrectly

As of this writing, GitHub thinks this repository consists of

• C 63.8%
• HyPhy 21.1%
• Brainfuck 13.9%
• Other 1.2%

(I don't even know what HyPhy is.)

I saw in some other repo that you can add a .gitattributes file which (among other things?) lets you say what the file extensions in the repo should be identified as.

On GitHub, this repo could use something like that.

put more example programs under (explicit) permissive license

@aturley and @mtve -- assuming you are who I think you are (and if you're not, please let me know) -- hi guys! Would you consider putting your old Befunge-93 example programs into the public domain (or at least under some kind of permissive license)? Not that I expect it makes much material difference, but it's a nice gesture, I find.

I'll also contact Wim Rijnders with the same question (but he doesn't appear to be on github.) I couldn't locate any other example authors for sure.

Audit compilability

Several of the C source files, in their header comments, claim they compile under certain compilers. In fact these claims have not been recently tested.

Before the final release of 2.24, but only after everything is merged into develop-2018-1, try to compile each C source on the following compilers-system combinations, and note the results more clearly in the header comments.

• Modern gcc on Ubuntu Linux
• Modern gcc on NetBSD
• DICE C on AmigaDOS 1.3
• DJGPP on FreeDOS
• Borland C++ 3.1 (if possible) on FreeDOS

If anyone reading this issue is equipped to compile C programs with a Metrowerks compiler (I guess this means CodeWarrior) on a Mac, they're free to see if those claims still hold; but I won't bank on this and will simply state that at one point it appears that they compiled under that combination.

Missing/incorrect authors for the example programs

Based on what I've been able to find in the archives of the Befunge mailing list, I think I know the authors of some of the uncredited example programs.

• rand6.bf, which is currently tentatively credited to Artyom Baranov, was actually written by you (on 1996/03/10).
• rand7.bf is the one that was written by Artyom N. Baranov (on 1996/02/28).
• selflist.bf was written by Dmitry Litvinov (on 1996/02/21).
• surprise.bf was written by Timothy Howe (on 1996/11/26).

Now we get to the more complicated issue of the quine mixup. You've got two 14-byte quines, selflis3.bf and selflis6.bf, which are identical. One is credited to Kevin Vigor, and one to Denis Moskowitz.

From what I can tell, Kevin come up with the first 14 byte quine (inspired by Ben Olmstead's 15 byte solution), but he got his loop length slightly wrong, so it was outputting an extra couple of spaces at the end that it shouldn't have. He posted a "fix" soon afterwards, but that was still off by one. And in the meantime, Denis had also noticed the problem, and posted a correct fix. So technically Denis was the first to post the correct version, but it was really just a trivial fix of Kevin's solution.

So that's the history - how you want to deal with the credits I'll leave up to you. But I do think having two identical examples is a bit confusing. And if you want a date for this, note that all of these solutions were posted on May 8th, 1997.

Then continuing the quine confusion, there are another four quines which are essentially just duplicates of some of the selflis set, only with a b97 directive header tacked on the front.

• revquine.bf is a copy of selflis2.bf
• quine.bf is a copy of selflis3.bf and/or selflis6.bf
• quine2.bf is a copy of selflis5.bf
• quine3.bf is a copy of selflist.bf, and has been miscredited (I believe) to Andrew Turley, since as far as I can tell, selflist.bf was written by Dmitry Litvinov, and at an earlier date than the one given in the quine3 header.

I'm not sure there's a whole lot of value in keeping these partial duplicates, but if you do, you should probably double check the credits of that last one.

And on a related noted, if you want an estimated date for Andrew Turley's sig, the oldest example I've seen of it was on a mailing lists post on October 30th, 1997. It was almost certainly not around before June 20th, since he was using a different version of the sig then (he'd had it in one form or another from at least February 1997).

I'm not sure why I spent so much time researching all of this, but there you are.

Fix for bridgeit.bf

Having read your comments about bridgeit.bf here, I decided to do some digging to see if I could find the BASIC book on which your implementation was based. And while I wasn't successful in that regard, I did come across a Personal Computing article from 1977 which described a winning strategy almost exactly like the one that you were using.

Once I knew how the game was supposed to work, and the strategy used to win, it didn't take that much to get the code working correctly. There were two or three values that were incorrect in the lookup table that determined the computers move. And some of the x coordinates were off by one in the table that determined the board output position. But most of the effort was just getting the board update code to work.

I didn't want to stray too far from your original design, but you really needed to output two different characters (| vs -) for different sections of the board, otherwise the bridges wouldn't make sense. And I also though it would be a good idea to overwrite both digits of the board number, otherwise the output was a bit messy. Unfortunately those two changes added a fair bit of complexity to the code.

But once I had the output working for the computer's move, it didn't require that much more effort to output the user moves as well - it was largely just cut and paste. So I thought that was worth adding too, because it really does make the game more playable.

The end result was this:

v >                                          v
 "Enter position of your move or 0 to quit: "<v
>1095+p                     vv*25             <
"  c    c    c    c    c   " <v*25
"h  1 h  2 h  3 h  4 h  5 h"  <v*25
"  c  6 c  7 c  8 c  9 c   "   <v*25
"h 10 h 11 h 12 h 13 h 14 h"    <v*25
"  c 15 c 16 c 17 c 18 c   "     <v*25
"h 19 h 20 h 21 h 22 h 23 h"      <v*25
"  c 24 c 25 c 26 c 27 c   "       <v*25
"h 28 h 29 h 30 h 31 h 32 h"        <v*25
"  c 33 c 34 c 35 c 36 c   "         <v*25
"h 37 h 38 h 39 h 40 h 41 h"          <v*25
"  c    c    c    c    c   ">#        #< #v*25    $# $# $#         v#
 AFGHIBCDEKJPQRSLMNOUTZ[\]VWXY_^defg`abcih>:#,_&:!#v_:95+g"@"-095+pv
738=BG5:?D38=BG5:?D38=BG5:?D38=BG5:?D38=BG
133333444455555666677777888899999::::;;;;;
v"My move is "                                                p+591<
>:#,_095+g:.v  v"I accept your wish to concede."*25<
  v,*25,"." <  >:#,_@
 ->97+g"/"-::2%!37*g\095+g96+g"0"-\p:2%45*g\095+g96+g"/"-\p 195v
-|vp\-"/"g+69g+591\g*73%2:p\-"0"g+69g+591\g*54!%2::-"/"g+79  g+<

I realise it's a bit late now, with version 2.25 having been released, but I thought you might appreciate it anyway, even if you don't want to add it back to the examples.