Determining EOF using fseek()?

[Orion]

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
doesn't seem to work well - it totally fumbles out actually:

while ((a = fseek(fp,0,SEEK _CUR)) == 0){
// code here
}

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.

[Chris Torek]

>Chris Torek wrote:

The second method could loop forever if run on an input file that
is (e.g.) on a bad floppy disk. ...
In article <news:ch******* *************** ***@theriver.co m>
RCollins <rc***@nospam.t heriver.com> wrote:

OK, you lost me here. I would think that if the source file or media
is corrupt, that *nothing* in C would be guaranteed to work correctly.
The source file is fine. The media from which the C programs are
run (local "hard drives", for instance) are also fine. The *input
file*, however, is on a bad floppy (or similar corrupt medium).

(Of course, we can postulate a single bad sector in the middle of
a data file on a "hard drive" -- incidentally, having been using
systems long before the PC popularized the silly phrase "hard
drive", I happen to find it annoying :-) -- with the rest of the
disk being OK. This results in the same problem. But I think it
may be easier to envision "good local disk, bad floppy".)
Why would one method (at the C level) work better than another?

The fgetc() call fails and returns EOF. Why? Is the reason for
the EOF return "because the attempt to read from the input file is
about to go past the known end-point of the file", or is it "because
the attempt to read from the input file failed even though we know
for sure we have not yet reached EOF"?

If the file system format on the floppy is such that the bad spot
does not affect the system's sure-ness of the original file size
-- i.e., if the file has some associated "metadata" that is still
readable and valid, so that we know the original input file should
be (say) 27812 bytes long -- and the error occurs when reading the
third sector (bytes 1024 through 1535 inclusive), the substrate
underlying the C system's standard I/O *should* report this as
"error reading file" (ferror(fp) becomes true) rather than "reached
end of file" (feof(fp) becomes true). The loop that tests for
feof(fp) will then run forever, attempting to read sector three
of the file again and again and again and again and again....
As a rule, if you ever see a "while (!feof(...))" loop in C, the
code is going to be wrong. The only place you should normally see
feof() or ferror() calls is inside an "if (...)". One can construct
exceptions to this rule, but in real code, it works pretty well:
be very suspicious of any loop controlled by an feof() call.

Again, I don't follow your reasoning. The "if (something)" and
"while (something)" constructs both expect "something" to be a logical
expression (evaluates either to 0 or non-0). Why is "if (feof(...))"
better than "while (feof(...))" ?

Pretty much for the same reason a biological-analysis program that
reads:

while (is_dead(subjec t_under_test))
do_some_stuff(s ubject_under_te st);

would be wrong: the subject is not going to spring to life again.[%]
Similarly, files do not normally suddenly become longer (so that
feof(fp) changes from "true" -- nonzero -- to zero), nor do they
normally have uncorrectable errors magically correct themselves
(so that ferror(fp) changes from nonzero to zero). Thus, it does
not make sense to repeat the test.
[% Dr Frankenstein's lab excepted, of course]

As I also said, there are exceptions (such as "tail -f" in the
Unix/POSIX world), but if you are using stdio, you must also use
the clearerr() function. Such exceptions will become obvious upon
the close scrutiny you should give a function that has an EOF or
error test as the controlling part of a "while" loop.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.