Date: Wed, 2 Jul 1997 17:41:12 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Michael Mauch <mauch AT uni-duisburg DOT de>
cc: djgpp AT delorie DOT com
Subject: Re: Possibly bug in fseek()
In-Reply-To: <5pdf4q$bmj$1@news-hrz.uni-duisburg.de>
Message-ID: <Pine.SUN.3.91.970702173320.28461B-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


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.