guy@sun.uucp (Guy Harris) (06/01/85)
> 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