bugs in cforth

[Guy Harris]

>    Found a couple of small things while getting the code
> up and running on our Pyramid:
> 
>  - Getblocks() wasn't recognizing the existance of
>    forth.block because fopen(blockfile,"a+") didn't
>    leave the pointer at the end of the file.  Fixed
>    it by inserting an fseek(blockfile,0L,2) after
>    the open.  This is definitely a Pyramid problem,
>    but I couldn't recreate it in my own tests.

If you do an 'fopen(..., "a+")' in the "att" universe on a Pyramid (or in
any other circumstance where you'd be using the System V standard I/O
library), the "fopen" doesn't do an "lseek" to the end - it just sets the
"forced append" bit on the underlying file descriptor, so that writes will
get stuck at the end *but* reads will read from the beginning.  Moral of the
story: if you want to have your code run on System V and non-System V
systems (V7 and S3 didn't do the "forced append" bit, either), *only* use
"a", not "a+", and only use that if you're going to append to a log file.
If you want to open a file for reading and writing without truncation, use
"open" and "fdopen".

Now for the S5 bug - why does it do the "lseek" when opening in "a" mode but
not in "a+" mode?  The "lseek" seems semi-pointless when opening in "a"
mode, since the forced-append mode guarantees that *all* writes go to the
end of the file, regardless of what seeks you do; you may argue that doing
the "lseek" makes an "ftell" return an offset indicating the end of the file
but an "ftell" on such a stream isn't very useful anyway, since all writes
have an implied seek to the end of the file?  On the other hand, doing the
"lseek" when you are opening "a+" makes it work more like pre-S5 versions of
the standard I/O library.

	Guy Harris