fseek() clears EOF?

Discussion in 'C Programming' started by ericunfuk, Mar 23, 2007.

  1. ericunfuk

    ericunfuk Guest

    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!
     
    ericunfuk, Mar 23, 2007
    #1
    1. Advertising

  2. ericunfuk

    Eric Sosman Guest

    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
    lid
     
    Eric Sosman, Mar 23, 2007
    #2
    1. Advertising

  3. ericunfuk

    Guest


    >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.
     
    , Mar 23, 2007
    #3
  4. ericunfuk

    Eric Sosman Guest

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

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

    --
    Eric Sosman
    lid
     
    Eric Sosman, Mar 23, 2007
    #4
  5. In article <>,
    <> wrote:

    >>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
     
    Walter Roberson, Mar 23, 2007
    #5
  6. On 23 Mar 2007 13:06:04 -0700, "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?


    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
     
    Barry Schwarz, Mar 23, 2007
    #6
  7. Barry Schwarz <> writes:
    > On 23 Mar 2007 13:06:04 -0700, "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?

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

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Mar 24, 2007
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Orion

    Determining EOF using fseek()?

    Orion, Aug 27, 2004, in forum: C Programming
    Replies:
    10
    Views:
    1,178
    Chris Torek
    Sep 5, 2004
  2. Xenos

    fseek past the eof

    Xenos, Nov 29, 2004, in forum: C Programming
    Replies:
    20
    Views:
    2,501
    Dan Pop
    Dec 1, 2004
  3. Kobu
    Replies:
    10
    Views:
    667
    Keith Thompson
    Mar 4, 2005
  4. SpreadTooThin

    ifstream eof not reporting eof?

    SpreadTooThin, Jun 13, 2007, in forum: C++
    Replies:
    10
    Views:
    722
    James Kanze
    Jun 15, 2007
  5. Orion

    Determining EOF using fseek()?

    Orion, Jun 29, 2011, in forum: C Programming
    Replies:
    6
    Views:
    758
Loading...

Share This Page