demco (02/18/83)
I have found a bug in the fseek() function of the stdio package as distributed by Berkeley (3/9/81). It can result in improper flushing with a stream file which has been opened for reading and writing (by specifying "r+", "w+", or "a+"). I don't know if the problem exists on System III or V. First, here is some background information about the stdio package. If a stream is opened for read/write, a flag bit called _IORW is set in the _iob structure for the file. Two other flag bits, _IOWRT and _IOREAD, indicate whether the file is currently being written or read. Changing from reading to writing or vice versa can only be done after reading an end of file, or calling fseek() or rewind(). In these cases the package tries to make sure that neither of the _IOWRT or _IOREAD bits are set, so you can subsequently do either a getc() or putc() and the package will enter reading or writing mode correctly. The problem is that fseek() called while in read mode can return with the file still in read mode. Subsequent putc()'s will not be written. A quick fix is to change resync = offset&01; to if (!(iop -> _flag & _IORW)) resync = offset & 01; else resync = 0; Can someone tell me what this "resync" business is all about? It looks like an attempt to keep the file's buffer aligned on an even byte offset into the file, but it won't do that in all cases. John Demco ubc-vision!demco