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

[j4james]

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.

[cpressey]

In the tradition of command-line flags such as -o, I would be in favour of making & behave like ~ in this respect (i.e., evaluate to -1 on EOF) while adding a flag (called, say, -u) which retains the existing behaviour.

[cpressey]

This is done. Closing.