David Thompson
7/11/2011 4:26:00 AM
On Wed, 29 Jun 2011 21:36:21 +0000 (UTC), Orion <won@bigpond.net.au>
wrote:
> Hey,
>
> I was wondering if it was possible to determine if you hit 'EOF' using
> fseek? I'm using fseek to traverse through the file from start to end
> and capturing the data into a linked list structure. However, my loop
I assume you are also reading because fseek can't 'capture ... data'.
And I guess you are skipping at least sometimes between reads, because
only then do you need fseek(); all C read (and write) operations
already advance the fileposition themselves.
> doesn't seem to work well - it totally fumbles out actually:
>
> while ((a = fseek(fp,0,SEEK_CUR)) == 0){
> // code here
>
> }
>
Nope. C doesn't require fseek() to detect if the new position, here
unchanged from old, is at or past EOF; and Unix (long the most
important platform for C implementation, though not the only one)
requires the opposite. In Unix it's entirely legal to fseek, or lseek,
beyond the current EOF, and if the file is writable and you write at
that position the file is extended to reach the point where you wrote,
with intervening zeros or as-if. Some filesystems optimize this case
by not actually storing (thus not actually zeroing) 'skipped' regions.
The seek fails only if the target position is not even representable.
C (and Unix) I/O doesn't 'look ahead' the way for example Pascal does.
A read operation that takes the last data before EOF succeeds. And in
some cases, more data may be added before you attempt the next read,
so the next read also succeeds. Only when you try to read and it
actually gets no data for *getc *gets *scanf etc. or less than
requested for fread does C treat that as EOF, and set feof().
And of course many (C) files aren't disk files. It's *impossible* to
know if you're 'about to EOF' on a terminal, a pipe, a socket, or a
magtape (not that anyone uses those anymore).
> Its quite important for me not to disrupt the current position of the
> cursor since I rely on that to fetch the data from the text file. I
> thought that the loop would work fine since fseek only returns a
> non-zero integer on an error but unfortunately this is not the case.
> Anyone with suggestions with using fseek() or some other function?
>
> Any help would be greatly appreciated! Thanks.
In standard C you have to try the input operation and *then* deal with
a return value that indicates EOF (or error).
If you want to limit yourself to disk files on bag-o-bytes systems --
which is just about all the ones people care about today -- you could
get the EOF value, either once at the begining if you assume or
enforce that no other process can append to the file and otherwise at
each check, and compare. The only 'standard' way is the fseek(,,END)
ftell() method -- and even that isn't officially guaranteed to work on
a binary file or to be comparable on a text file, but on a bag-o-bytes
implementation not to work the obvious way would be crazy. The
nonstandard way is stat() on Unix or its equivalent elsewhere.
But note you still need to deal with errors, which may occur on a read
operation even after you have correctly determined you are not at EOF,
so this actually makes your logic more complicated not less.