fseek() clears EOF?

[ericunfuk]

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?

Thank YOU!

 

[Eric Sosman]

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?

 

[wumei2010]

It clears the
stream's "I've hit the end of the file" indicator, which

Here "clears" doesn't mean EOF is removed, right?i.e. it doesn't mean
the stream could go beyond the actual end of the file. e.g. if the
stream representing the original file is from memory location 0 to 10,
when I fseek() from position 9, 3 locations, you will still get the
EOF set for the stream right?9+3 is beyond the original stream
representing the original file.

 

[Eric Sosman]

Here "clears" doesn't mean EOF is removed, right?

The end-of-file indicator is part of the stream, not part
of the file. Again, I suggest you consider what changes are
made to a read-only file when you fseek() a stream that's
reading from it.

i.e. it doesn't mean
the stream could go beyond the actual end of the file.

Different file systems handle this differently, so C doesn't
try to tell them all how to behave on an off-the-end fseek().
On some systems the fseek() will fail. On others, the fseek()
may succeed but a subsequent attempt to read will fail. On
yet others, it is possible to fseek() past the end of the file
and start writing, producing a "sparse" file.

But none of these really has anything to do with "clearing
the end-of-file indicator." That indicator reports the state
of the stream, not of the file it's attached to.

e.g. if the
stream representing the original file is from memory location 0 to 10,
when I fseek() from position 9, 3 locations, you will still get the
EOF set for the stream right?9+3 is beyond the original stream
representing the original file.

Here you've lost me: I don't understand how "memory locations"
enter into the picture.

 

[Walter Roberson]

It clears the
stream's "I've hit the end of the file" indicator, which

[/QUOTE]

Here "clears" doesn't mean EOF is removed, right?i.e. it doesn't mean
the stream could go beyond the actual end of the file. e.g. if the
stream representing the original file is from memory location 0 to 10,
when I fseek() from position 9, 3 locations, you will still get the
EOF set for the stream right?9+3 is beyond the original stream
representing the original file.

Your wording is a bit ambiguous.

What you need to know is:
- EOF is a value (always negative) that will be returned by some read
operations to signal that the end of stream has been reached (or
exceeded).

- There is an internal end-of-file indicator for each stream. That
indicator is almost always stored in a completely different way than by
setting something internal to the particular value EOF. So you have to
distinguish the -value- EOF that will be returned by some operations to
indicate that the end-of-file indicator is set.

- If you fseek() past the EOF, then doing so is a valid operation, and
clears the internal end-of-file indicator associated with the stream.

- In C, if the current position is at or beyond the end of the stream,
and you attempt to read more data, an appropriate end-of-file indicator
will be returned. The exact indicator depends on the exact variety of
read call but is often by returning the value EOF

- In C, the end-of-file indicator being set, as detectable by feof(),
does not mean that the system somehow "knows" that the next read
attempt would fail -- it is, for example, not set when you read the
last character of a stream. Instead, the end-of-file indicator flag, as
detectable by feof(), is only set when the program attempts a read and
that read does not succeed because the position is at or beyond the end
of the stream.

- There is good reason for the implementation NOT to set the
end-of-file indicator upon reading the last existing character: namely,
that there might be more data for the stream that will arrive later,
such as if the stream is associated with an input device (e.g., user &
keyboard) or the stream is associated with a network socket.

- Thus, the internal end-of-file indicator does not indicate that
the next I/O will be at (or beyond) the end of stream: it indicates
instead that the -previous- I/O was at (or beyond) the end of stream.
So the internal end-of-file indicator can be cleared in various ways
without affecting what would happen if another read were to be
attempted.


Additionally:
- The C89 standard does not define exactly what happens if you write
new data (on a writable stream) when you are positioned past the end of
the stream. There is another widely used standard for operating system
interfaces, POSIX.1, which does specify the behaviour in such a
situation, at least on systems that conform to that standard. (The
POSIX.1 standard says that in such a case that the write is valid, and
that all data between the previous end of stream and the new position
will read back as binary zeroes unless other data is written into the
gap.)

 

[Barry Schwarz]

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?

The EOF indicator is set only when you try to read past the last
character in the file, not when you read the last character. If you
fseek(), you are repositioning the file such that you not yet tried
to read past the end. Even when you fseek() to the end of the file,
you are positioning at the end, as if you had just read the last
character but no more. Since you have not tried to read past the last
character, the indicator is reset.


Remove del for email

 

[Keith Thompson]

The EOF indicator is set only when you try to read past the last
character in the file, not when you read the last character. If you
fseek(), you are repositioning the file such that you not yet tried
to read past the end. Even when you fseek() to the end of the file,
you are positioning at the end, as if you had just read the last
character but no more. Since you have not tried to read past the last
character, the indicator is reset.

I think it's important to keep the terminology straight. There is no
"EOF indicator"; there is an "end-of-file indicator".

The end-of-file indicator is an internal flag, associated with a
stream, that indicates that records whether the end of the file has
been reached (C99 7.19.1p2). The feof() function can be used query
the end-of-file indicator, but that's less useful than you might
think.

EOF is a macro, defined in <stdio.h>, "which expands to an integer
constant expression, with type int and a negative value, that is
returned by several functions to indicate end-of-file, that is, no
more input from a stream" (C99 7.19.1p3).

If, for example, you're reading a file using the fread() function,
then you can detect an end-of-file condition by checking the value
returned by fread(); EOF is not involved.