Hi,
A successful call to fseek() shall clear the end-of-file indicator for the stream and undo any effects of ungetc() and ungetwc() on the same stream. After an fseek() call, the next operation on an update stream may be either input or output.
}
- /* Clear end of file */
- file->_flag &= ~MSVCRT__IOEOF; return (_lseek(file->_file,offset,whence) == -1)?-1:0;
What if you try to fseek to the end of file (SEEK_END)? Should IOEOF flag be cleared in this case? And may _lseek() function be better place for this?
Current _lseeki64() implementation contains FIXME concerning the same issue: MSVCRT_fdesc[fd].wxflag &= ~(WX_ATEOF|WX_READEOF); /* FIXME: What if we seek _to_ EOF - is EOF set? */
-- Kirill
Kirill K. Smirnov wrote:
What if you try to fseek to the end of file (SEEK_END)? Should IOEOF flag be cleared in this case?
I believe that for a standards conforming fseek it should be. See:
http://www.opengroup.org/onlinepubs/000095399/functions/fseek.html
For standards conforming behaviour fseek(f,0,SEEK_END) clears the flag, and the next fread will return 0 and set it again.
However, I realize that for wine, the standards are pretty much moot as wine attempts to be bug compatible with windows. Obviously some more testing (on windows and wine) is required.
And may _lseek() function be better place for this?
I don't think so. _lseek keeps its own flags.
Erik