From: mauch AT uni-duisburg DOT de (Michael Mauch)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Possibly bug in fseek()
Date: Wed, 02 Jul 1997 13:48:01 +0200
Organization: Home, sweet home (via Gesamthochschule Duisburg)
Lines: 70
Message-ID: <5pdf4q$bmj$1@news-hrz.uni-duisburg.de>
References: <5pb9t9$1if$1 AT news-hrz DOT uni-duisburg DOT de> <33B96225 DOT 7E4F AT cornell DOT edu>
NNTP-Posting-Host: ppp51.uni-duisburg.de
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

On Tue, 01 Jul 1997 16:01:41 -0400, "A. Sinan Unur" <asu1 AT cornell DOT edu>
wrote:

> this is what the ANSI standard says (according to an excerpt on p.249 of
> Plauger's "The Standard C Library")
> 
> 7.9.9.2
> ...
> A binary stream need not meaningfully support fseek calls with a whence
> value of SEEK_END.

Hmm, too bad. I always thought that seeking in _text_ files is a bad
idea because of the CR/LF problem.

> Returns:
> 
> The fseek function returns nonzero only for a request that cannot be
> satisfied.

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?
 
> compare the first line of your post with this information.

Hmm, you don't mean the "Hi!", do you?  ;-)

I wanted to open the file in binary mode, and I wanted to seek before
the start of the file. 

Info-ZIPs Zip 2.2m beta uses this technique, too, and when I was trying
to track down a bug, I found this (in my eyes still) strange behaviour
of fseek(). I think I should check with the Info-ZIP guys to find out
whether that's a bug in their beta or an incompatibility with the DJGPP
(i.e. ANSI) version of fseek().

But, OTOH, are there any strong concerns that existing code could break,
if fseek() would just support the usage of SEEK_END for binary streams?
IMHO this is not explicitly forbidden by Plauger or the standard. And if
it is common practice on UNIX and other systems (I don't know whether it
is!), wouldn't it be a good idea to do it just the same?

Now, I tested it with LCC (Win32-console) and emx-gcc (DOS): both return
-1.
BC++ 4.52 returns 0, on the other hand.

But why does the implementation of fseek() rely on lseek() to return -1
on error? libc.info says:

>>>
Return Value
------------

The new offset is returned.
<<<

So lseek() is probably not guaranteed to return -1 on error. The ANSI-C
rationale says that lseek() is not defined by the ANSI standard, but "A
suggested semantics for these functions in the UNIX world may be found
in the emerging IEEE P1003 standard", that's POSIX, I guess.

Thinking about it: what else options do we have to portably seek in
binary files?

Regards...
		Michael
-- 
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