finding the eof

nodger · 11-25-2004, 09:28 AM

Another descriptor question... Is there any function for finding out if Ive reached the end of file? ie. An equivalent of feof()

perfect_circle · 11-25-2004, 09:45 AM

what do you want eof for?
when you read a file,
in most cases you just do

Code:

c = getc(fd);
while( c != EOF)
     c=getc(fd);

or someting like that.
be more specific, give an example

jlliagre · 11-25-2004, 09:51 AM

Feof is clearly a library call that has no back-end system call equivalent.
It just tell if a previous read has failed because of a EOF condition.

nodger · 11-25-2004, 09:52 AM

nope, im converting some code from using file pointers to use unix descriptors instead, and since theres no feof() equivalent for using with descriptors (that I can find) , Im wondering whats the easiest way to mimic the behaviour of feof. As far as I can see the only way is using the read() function and checking if it returns the same amount of bytes, but I KNOW theres a more proper way to do it

Hko · 11-25-2004, 10:36 AM

stdio's feof() only returns true if the last fgets(), fread(), or whatever has already hit the end-of-file.

Of course you can do the same with read() from a filedescriptor.
According to "man 2 read":

Quote:

RETURN VALUE
On success, the number of bytes read is returned (zero indicates end of file) [...]

So you can easily implement your own feof() (use a different name though, let's say "f_eof()" ) for file descriptors just by checking if a dummy read() returns 0:

Code:

#include <unistd.h>

int f_eof(int fd)
{
    int dummy_buf;
    return (read(fd, &dummy_buf, 1) == 0);
}

I'm quite sure there's no other way, not really different anyway.

P.S. Happy birthday

perfect_circle · 11-25-2004, 10:37 AM

Quote:

As far as I can see the only way is using the read() function and checking if it returns the same amount of bytes, but I KNOW theres a more proper way to do it

in the next read after u reach the end of file, read will return -1 which is the error for EOF.(You probably know that). This is what the stream functions check, since fopen,fclose,feof, etc are all constucted using basic I/O functions (read,write,open etc.)

Hko · 11-25-2004, 10:40 AM

Quote:

Originally posted by perfect_circle
in the next read after u reach the end of file, read will return -1 which is the error for EOF.

No.
If read() returns -1 it's a real error.
read() returns 0 on EOF.

jlliagre · 11-25-2004, 11:08 AM

By the way, in case of no EOF condition, reading one byte would hide it from the next read calls, don't forget to store it somewhere in your library and bring it back to the next read ...

Quote:

but I KNOW theres a more proper way to do it

If you KNOW, don't ask, tell us !

Frankly speaking, I'm afraid you're trying to reinvent the wheel, and that you'll be disappointed by the performance gain, you'll reach, if any ...

Hko · 11-25-2004, 11:18 AM

Quote:

Originally posted by jlliagre
By the way, in case of no EOF condition, reading one byte would hide it from the next read calls, don't forget to store it somewhere in your library and bring it back to the next read ...

Oops, I forgot that part.
Thanks for catching that.

nodger · 11-25-2004, 01:01 PM

Quote:

If you KNOW, don't ask, tell us !

Frankly speaking, I'm afraid you're trying to reinvent the wheel, and that you'll be disappointed by the performance gain, you'll reach, if any ...

Alright I get the message! - BTW there was no performance gain but a big performance drop. Still I feel its more standard this way and therefore better for porting.

I can always make the code more efficent when it actually becomes something important to me

Hko · 11-25-2004, 06:52 PM

Quote:

Originally posted by nodger
Alright I get the message! - BTW there was no performance gain but a big performance drop.

How big are the buffers you're read()ing data into?

perfect_circle · 11-25-2004, 09:42 PM

Code:

No.
If read() returns -1 it's a real error.
read() returns 0 on EOF.

That's true...sorrrrrrrrryyyyyyyy!!!

Quote:

Alright I get the message! - BTW there was no performance gain but a big performance drop. Still I feel its more standard this way and therefore better for porting.

in C streams are used for many many years (more than 20), I would agree with jlliagre. What you are trying to do is pointless.

jlliagre · 11-26-2004, 02:17 AM

Quote:

in C streams are used for many many years (more than 20)

Correct, precisely 25 years.
Here's an excerpt of the venerable Unix Version 7 manual, dated January, 1979.

Quote:

Standard I/O.
The old fopen, getc, putc complex and the old -lp package are both dead, and even
getchar has changed. All have been replaced by the clean, highly efficient, stdio(3) package. The first
things to know are that getchar(3) returns the integer EOF (-1), which is not a possible byte value, on
end of file, that 518-byte buffers are out, and that there is a defined FILE data type.