Message-Id: <199707021954.PAA01154@delorie.com> From: mauch AT unidui DOT uni-duisburg DOT de (Michael Mauch) To: Eli Zaretskii Cc: djgpp AT delorie DOT com Subject: Re: Possibly bug in fseek() Date: Wed, 02 Jul 1997 21:35:20 +0200 Organization: Home, sweet home (via Gesamthochschule Duisburg) References: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk On Wed, 2 Jul 1997 17:41:12 +0300 (IDT), Eli Zaretskii wrote: > 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? Yes. > If so, why is it a problem > when you get moved to the beginning of the file? 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, IMHO. OTOH, if this is what other compilers do (and other people expect fseek() to do), then my idea to redesign fseek() is probably a bad idea. > 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.) Yes, I think it's best to keep in mind (*) that the behaviour of fseek() is not completely ANSI-standardized and DJGPP supports one commonly used practice but not the other, because there's no way to support both of them. 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. 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. Ok, it was all my (or InfoZIP's) fault. > `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. DJGPP's lseek() happily moves the file pointer to a negative value, e.g. -3651. From that imaginary position you can seek to the start of the file again with lseek(fd,+3651,SEEK_CUR). Probably that's also one of the expected behaviours of some or many lseek() implementations. The same holds true for fseek(). Regards... Michael *: 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. **: Suggestion: When using SEEK_END, be aware that the ANSI-C standard does not define a specific behaviour if you try to move the file pointer before the beginning of the file. Some implementations of fseek() return an error (i.e. nonzero) in this situation, others and DJGPP don't. The DJGPP implementation moves the file pointer to an imaginary negative position and returns 0. From that position, you can fseek() forward to any position you like. For portable programs, it's a good idea to use ftell() after fseek() to check where the file pointer really has been set. -- PGP key (0x013CB889) available at public key servers. PGP mail welcome. PGP fingerprint: 83 D1 C4 76 0A F5 35 C6 C6 C4 C8 73 1B 45 E9 D5