Mail Archives: djgpp/1997/07/02/10:47:08
On Wed, 2 Jul 1997, Michael Mauch wrote:
> So, given that the DJGPP implementation of binary streams does "not
> meaningfully support fseek", shouldn't fseek() then always fail for this
> "request that cannot be satisfied", i.e. using SEEK_END on binary
> streams?
If I remember correctly your original posting, you tried to move from the
end of the file by more than the file size? If so, why is it a problem
when you get moved to the beginning of the file? If not, what was the
exact problem?
I'm not aware of any problems with `fseek' in its current implementation,
neither with binary nor with text files. It is true that ANSI doesn't
require much from a compliant library as far as `fseek' is concerned, but
DJGPP v2.01 goes out of its way to make its `fseek' support every wild
request. (In fact, the entire buffered I/O machinery was redesigned for
DJGPP 2.01 with the sole purpose of making `fseek' and `ftell' work
better.)
> So lseek() is probably not guaranteed to return -1 on error.
`lseek' in DJGPP just calls the relevant DOS function. Only if DOS
returns an error indicator, does `lseek' return -1. I guess in your case
the file pointer gets moved to the beginning of the file, which isn't so
unreasonable, given that this is what DOS does.
- Raw text -