Mail Archives: djgpp/1997/07/03/13:13:47
On Wed, 2 Jul 1997, Michael Mauch wrote:
> Because I tried to move _before_ the beginning of the file, and this
> request can't be satisfied by fseek(), so I think it should report an
> error and not silently move me to a place where I didn't want to go,
Well, that's one way of thinking about this. Another way is to remember
that `fseek' just moves the file pointer, that is, it's a filesystem
operation (albeit complicated by the stdio buffering). So if the
operating system moves you to the beginning of the file in such cases and
doesn't return with an error, it means the request _can_ be satisfied,
sort of.
> On the INFO-ZIP list, somebody told that my test program returned 0 when
> compiled with Watcom 7 for 16bit DOS and -1 with Watcom 9.5c for OS/2
> (32 bit). The same is true with Borland C++ 4.52: the 16-bit version
> gives 0, the Win32-console version gives -1. So there's really no way to
> rely on a standard behaviour.
This just confirms that the difference in the behavior is caused by the
underlying OS call, not by the library code. OS/2 and Win32 VFAT return
an error in such cases, while DOS doesn't. That is probably the single
most important reason why ANSI specifies so little of standard `fseek'
behavior: it's just too damn OS-dependent.
> Moreover, my test program (and the InfoZIP people's Zip 2.2m beta)
> probably could use ftell() after fseek(,,SEEK_END) to check where the
> fseek() moved the file pointer - or ask ftell() before fseek(), to check
> if the file is large enough.
That would be much more portable, yes.
> *: Maybe it's possible to include such a hint (**) in the libc.info
> file, for those of us who are suffering from Alzheimer's disease and
> can't keep in mind all the standards and not-standards.
Good idea. Thanks for the suggested addition to the docs.
- Raw text -