ericunfuk wrote:
> A basic question:
>
> When the documentation says "fseek() clears EOF indecator, does it
> mean when you seek over EOF, EOF is no longer at the original position
> and hence removed?Say, after I seek over the original EOF, when I
> fread() from a previous position that I know is before the EOF then
> fread will not be able to tell if it has encountered the original EOF?
You need to separate the notions of "file" and "stream."
The "file" is the ultimate source or sink of data: It
could be a keyboard or a network interface or a sound board.
For ease of explanation, let's assume for now that it's a
fixed amount of data sitting on a disk somewhere.
The "stream" is the connection between the program and
a "file." It is the conduit through which data flows to and
from the file. For files where the notion makes sense, the
stream also keeps track of the "current position" within the
file, that is, the place in the file to or from which the
next character will be transferred.
Finally, the stream also maintains a few indicators to
help the program find its way. One of these is the EOF
indicator, which gets set whenever a read bumps up against
the end of the file.
With this in mind, you'll see that clearing the EOF
indicator does nothing at all to the file! It clears the
stream's "I've hit the end of the file" indicator, which
makes sense because when you fseek() you're telling the
stream to start over at another position in the file; the
information that "I'm at the end" is no longer accurate.
Here's a thought experiment -- or even an actual experiment;
go ahead and try it. Open two different input streams on the
very same file, simultaneously. Read from one of them, and keep
reading until you reach the end of the file. If you then read
from the second stream, what do you expect should happen?
Second thought experiment: Suppose the disk that holds the
file is a read-only device like a CD-ROM. In what ways can
fseek() change the file?
--
Eric Sosman
esosman@acm-dot-org.invalid