In article <11*********************@n59g2000hsh.googlegroups. com>,
<wu*******@googlemail.comwrote:
>>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.
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.)
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest
