Date: Thu, 20 Mar 1997 18:13:53 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Christopher Keane <keane AT jei DOT umd DOT edu>
cc: djgpp AT delorie DOT com
Subject: Re: fseek() bug?!?!
In-Reply-To: <5gplk9$fpn@hecate.umd.edu>
Message-ID: <Pine.SUN.3.91.970320181328.24420N-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On 19 Mar 1997, Christopher Keane wrote:

> It appears that fseek resets the error condition on EOF, causing this 
> loop to fail.  I solved this with checking the feof() before the fseek() 
> and breaking, but I don't understand why this should fail.

AFAIK, this is exactly how ANSI requires `fseek' to work.  ANSI C
standard explicitly says (para 7.9.9.2):

	A successfull call to the `fseek' function clears the
	end-of-file indicator for the stream

However, the standard doesn't specify at all that `fseek' should set
the EOF flag when you seek past the end of the file, which is entirely
possible and legitimate operation.  Since anything that isn't
specified by ANSI C is open to interpretation, your program should not
rely on any specific behavior in these cases.

Btw, did you open that stream in binary mode?  If not, you shouldn't
even assume to get any meaningful results when you call `fseek' with
anything other than 0 or a value returned by a call to `ftell', and
the 3rd parameter to `fseek' should be always SEEK_SET, because these
are the only cases that ANSI specifies.  You are lucky that in DJGPP
v2.01 `fseek' works for a much more broad array of cases for text
streams (in v2.0, it did not).