>>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