Date: Thu, 3 Jul 1997 18:06:48 +0300 (IDT) From: Eli Zaretskii To: Michael Mauch cc: djgpp AT delorie DOT com Subject: Re: Possibly bug in fseek() In-Reply-To: <199707021934.WAA28971@is.elta.co.il> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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.