Question

DISCLAIMER: Don’t use ::feof() as your loop condition. For example, see the answer to: file reading: feof() for binary files

However, I have “real” code that demonstrates a problem that does not use ::feof() as my loop condition, but LOGICALLY, this is the easiest way to demonstrate the problem.

Consider the following: We iterate a character stream one-at-a-time:

FILE* my_file;
// ...open "my_file" for reading...

int c;
while(0 == ::feof(my_file))
{ // We are not at EOF
  c = ::getc(my_file);
  // ...process "c"
}

The above code works as expected: The file is processed one-char-at-a-time, and upon EOF, we drop out.

HOWEVER, the following has unexpected behavior:

FILE* my_file;
// ...open "my_file" for reading...

int c;
while(0 == ::_eof(::fileno(my_file)))
{ // We are not at EOF
  c = ::getc(my_file);
  // ...process "c"
}

I would have expected them to perform the same. ::fileno() properly returns the (integer) file descriptor every time. However, the test ::_eof(::fileno(my_file)) works exactly once, and then returns 1 (indicating an EOF) on the second attempt.

I do not understand this.

I suppose it is conceivable that ::feof() is “buffered” (so it works correctly) while ::_eof() is “un-buffered” and thinks the whole file is “read-in” already (because the whole file would have fit into the first block read in from disk). However, that can’t possibly be true given the purpose of those functions. So, I’m really at a loss.

What’s going on?

(Files are opened as “text”, are ASCII text files with about a dozen lines, MSVS2008, Win7/64.)

Answer 1

I suppose it is conceivable that ::feof() is “buffered” (so it works
correctly) while ::_eof() is “un-buffered” and thinks the whole file
is “read-in” already (because the whole file would have fit into the
first block read in from disk). However, that can’t possibly be true
given the purpose of those functions. So, I’m really at a loss.

I don’t know why you would think it “can’t possibly be true given the purpose of those functions.” The 2 functions are meant to operate on files that are opened and operated on in different ways, so they are not compatible.

In fact, that is exactly what is happening. Try this:

FILE* my_file;
// ...open "my_file" for reading...

int c;
while(0 == ::_eof(::fileno(my_file)))
{ // We are not at EOF
  c = ::getc(my_file);

  long offset1 = ftell(my_file);
  long offset2 = _tell(fileno(my_file));

  if (offset1 != offset2)
  {
     //here you will see that the file pointers are different
     //which means that _eof and feof will fire true under different conditions
  }
  // ...process "c"
}

I will try to elaborate a bit based on your comment.

When you call fopen, you are getting back a pointer to a file stream. The underlying stream object keeps it’s own file pointer which is separate from the actual file pointer associated with the underlying file descriptor.

When you call _eof you are asking if you have reached the end of the actual file. When you call feof, you are asking if you have reached the end of the file stream. Since file streams are usually buffered, the end of the file is reached before the end of the stream.

I’m still trying to understand your answer below, and what the purpose
is for _eof() if it always returns 1 even when you didn’t read
anything (after the first char).

To answer this question, the purpose of _eof is to determine if you have reached the end of the file when using _open and _read to work directly with file descriptors, not when you use fopen and fread or getc to work with file streams.