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.

[Villy Kruse]

On Fri, 27 Aug 2004 14:08:23 GMT,
Orion <wo****@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
doesn't seem to work well - it totally fumbles out actually:

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

I wouldn't expect this would ever return an error as long as fp is a valid
FILE pointer representing a seekable file. The normal way to determine
eof is to read from the file and see if it returns an eof indication.

Villy

[Eric Sosman]

Orion 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. [...]

If you're reading the whole file "from start to end," why
are you using fseek() at all? Just keep calling fgets() or
fread() or whatever you're using to soak up the data, and when
you get to end-of-file the function will tell you so[*] by
returning the value EOF.
[*] The EOF return value can also indicate an actual I/O
error rather than end-of-file. For belt-and-suspenders
certainty, you can use feof() or ferror() to figure out
what the EOF value actually meant.

--
Er*********@sun .com

[Karthiik Kumar]

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

Of course, there is feof(fp) for these purposes.

--
Karthik.

[Chris Torek]

>Orion wrote:

I was wondering if it was possible to determine if you hit 'EOF' using
fseek?

(The correct answer is "no", as I believe others have already
posted. Unix-like systems allow a quite simple demonstration: open
a file for both reading and writing, seek to a position many
gigabytes past the existing EOF, and write one byte. The file is
suddenly that much longer. [Note that modern Unix-like systems
support multi-terabyte files. Of course, you cannot use fseek()
to do this unless LONG_MAX is more than 2147483647, e.g., on Itanium
or Alpha.] Since you can seek to any location, including nonexistent
beyond-current-EOF locations, in order to extend a file, it
necessarily follows that seeks past the existing EOF do not fail
-- at least if the file is open for writing. As it happens, this
holds for read-only files as well.)

In article <news:41300fa4$ 1@darkstar>
Karthiik Kumar <ka************ *****@yahoo.com > wrote: Of course, there is feof(fp) for these purposes.

feof(fp) is not "for those purposes". The feof() function has only
one purpose: after an attempt to read fails, feof() and ferror()
distinguish between the two possible reasons for such a failure: EOF,
or error.

The read failure *must* occur first, though.
--
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.

[lawrence.jones]

Karthiik Kumar <ka************ *****@yahoo.com > wrote:

Of course, there is feof(fp) for these purposes.

No, there isn't. feof() doesn't tell you if trying to read *will*
return EOF, it only tells you if a previous read *already returned* EOF.

-Larry Jones

I've never seen a sled catch fire before. -- Hobbes

[Anand]

Orion <wo****@bigpond .net.au> wrote in message news:<rf******* **********@news-server.bigpond. net.au>...

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.

Hi

To read all characters from a text file upto EOF better u can go
for feof
function. Iam giving an example so that u can understand

Method1:

FILE *Fp;
int ch;

Fp=fopen("c:\\t est.txt","rb");

while((ch=fgetc (Fp))!=EOF)
printf("%c",ch) ;

fclose(Fp);

Method2:

File *Fp;
char ch;

Fp=fopen("c:\\t est.txt","rb");

ch=fgetc(Fp);

while(!feof(Fp) )
{

printf("%c",ch) ;
ch=fgetc(Fp);
}

fclose(Fp);

The above two methods will work correctly. The reason EOF value is
FFFF.
It will go beyond the range. so normally an unsigned char cannot able
to hold the value of EOF. So u can get an logical error while reading
entire file becus
fgetc will treat EOF as character. Hope these ideas will make u
clear.

regards,

Anand.

[Chris Torek]

In article <news:cd******* *************** **@posting.goog le.com>
Anand <an********@yah oo.co.in> wrote:

To read all characters from a text file upto EOF better u can go
for feof function.
This is not a good idea.
Method1: [snipped -- it should work, although it seems peculiar to fopen()
a file named "test.txt" with "rb" -- binary -- mode.]
Method2:

File *Fp;
char ch;

Fp=fopen("c:\\t est.txt","rb");

ch=fgetc(Fp);

while(!feof(Fp) )
{

printf("%c",ch) ;
ch=fgetc(Fp);
}

fclose(Fp);

The above two methods will work correctly.
The second method could loop forever if run on an input file that
is (e.g.) on a bad floppy disk. (Remember floppies? :-) ) Suppose
fgetc() attempts to read a sector off the floppy, but the sector
is bad. The read will fail, but *not* because of end-of-file.
The C standard then suggests that feof(Fp) should return 0, and
ferror(Fp) should return some nonzero value. This is indeed what
happens on some real systems.
The reason EOF value is FFFF.
Actually, EOF is a macro "#define"d in <stdio.h> to some negative
integral value (often just -1, but any negative integral value is
allowed).
It will go beyond the range. so normally an unsigned char cannot able
to hold the value of EOF.

The value EOF expands to may or may not be outside the range of a
plain (and thus possibly signed) "char". It is indeed outside the
range of an unsigned char, and if EOF is #defined to -1, the result
of:

unsigned char uc = EOF;

is to set uc to UCHAR_MAX, by definition. But this is rarely 0xffff;
more commonly, this is 0xff.

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

[RCollins]

Chris Torek wrote:

In article <news:cd******* *************** **@posting.goog le.com>
Anand <an********@yah oo.co.in> wrote:

To read all characters from a text file upto EOF better u can go
for feof function.

This is not a good idea.

Method1:

[snipped -- it should work, although it seems peculiar to fopen()
a file named "test.txt" with "rb" -- binary -- mode.]

Method2:

File *Fp;
char ch;

Fp=fopen("c:\\t est.txt","rb");

ch=fgetc(Fp);

while(!feof(Fp) )
{

printf("%c",ch) ;
ch=fgetc(Fp);
}

fclose(Fp);

The above two methods will work correctly.

The second method could loop forever if run on an input file that
is (e.g.) on a bad floppy disk. (Remember floppies? :-) ) Suppose
fgetc() attempts to read a sector off the floppy, but the sector
is bad. The read will fail, but *not* because of end-of-file.
The C standard then suggests that feof(Fp) should return 0, and
ferror(Fp) should return some nonzero value. This is indeed what
happens on some real systems.

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.
Why would one method (at the C level) work better than another?

The reason EOF value is FFFF.

Actually, EOF is a macro "#define"d in <stdio.h> to some negative
integral value (often just -1, but any negative integral value is
allowed).

It will go beyond the range. so normally an unsigned char cannot able
to hold the value of EOF.

The value EOF expands to may or may not be outside the range of a
plain (and thus possibly signed) "char". It is indeed outside the
range of an unsigned char, and if EOF is #defined to -1, the result
of:

unsigned char uc = EOF;

is to set uc to UCHAR_MAX, by definition. But this is rarely 0xffff;
more commonly, this is 0xff.

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(...))" ?

--
Ron Collins
Raytheon Air Defense/RTSC/BCS

[Joe Wright]

RCollins wrote:

Chris Torek wrote:

In article <news:cd******* *************** **@posting.goog le.com>
Anand <an********@yah oo.co.in> wrote:

To read all characters from a text file upto EOF better u can go
for feof function.

This is not a good idea.

Method1:

[snipped -- it should work, although it seems peculiar to fopen()
a file named "test.txt" with "rb" -- binary -- mode.]

Method2:

File *Fp;
char ch;

Fp=fopen("c:\\t est.txt","rb");

ch=fgetc(Fp);

while(!feof(Fp) )
{

printf("%c",ch) ;
ch=fgetc(Fp); }

fclose(Fp);

The above two methods will work correctly.

The second method could loop forever if run on an input file that
is (e.g.) on a bad floppy disk. (Remember floppies? :-) ) Suppose
fgetc() attempts to read a sector off the floppy, but the sector
is bad. The read will fail, but *not* because of end-of-file.
The C standard then suggests that feof(Fp) should return 0, and
ferror(Fp) should return some nonzero value. This is indeed what
happens on some real systems.

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.
Why would one method (at the C level) work better than another?

The reason EOF value is FFFF.

Actually, EOF is a macro "#define"d in <stdio.h> to some negative
integral value (often just -1, but any negative integral value is
allowed).

It will go beyond the range. so normally an unsigned char cannot able
to hold the value of EOF.

The value EOF expands to may or may not be outside the range of a
plain (and thus possibly signed) "char". It is indeed outside the
range of an unsigned char, and if EOF is #defined to -1, the result
of:

unsigned char uc = EOF;

is to set uc to UCHAR_MAX, by definition. But this is rarely 0xffff;
more commonly, this is 0xff.

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(...))" ?

The canonical method for reading a file to the end is..
int c;
FILE *in;
....
while ((c = fgetc(in)) != EOF) {

}
Now when fgetc() detects EOF it is before the loop executes for that
character. After the loop test "if (!feof(in)) {}" to know whether
EOF meant end-of-file or was an error.

If the control was "while (!feof(...))" with "c = fgetc(in)" inside
the loop, the loop is executed with c == EOF which is probably not
what you want.

--
Joe Wright mailto:jo****** **@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---