What if you read the file correctly with binary file I/O functions?
What if you read the file correctly with binary file I/O functions?
The idea is that you may not always be reading a text file - So you can't rely on what you have just read to determine whether you have read is the end of the file
Fact - Beethoven wrote his first symphony in C
I'm starting to get annoyed with this argument. There is nothing that says EOF directly relates to how feof() works. When fgetc() does a read, it will ignore the high order bits, anyway.
This is from C File I/O Tutorial - Cprogramming.comOriginally Posted by whiteflags
When fread is used, after being passed an array, fread will read from the file until it has filled the array, and it will return the number of elements actually read. If the file, for example, is only 30 bytes, but you try to read 100 bytes, it will return that it read 30 bytes. To check to ensure the end of file was reached, use the feof function, which accepts a FILE pointer and returns true if the end of the file has been reached.
Fact - Beethoven wrote his first symphony in C
That quote agrees with me if anything. If the content of a file can break feof() then your implementation is broken.
... The content of a file can't break feof() - The quote (to me) says that when using fread, where is a risk that you may miss some data at the end of the file without knowing it unless you check to see if the end of the file was reached with the feof() function. How did you get "can break feof()" from that?
But just to clarify, we are both agree that there is a place for feof(), which is what oogabooga asked for?
Fact - Beethoven wrote his first symphony in C
How did you get "can break feof()" from that? whiteflags certainly did not conclude that that part of the standard says that feof is broken, but it is you who used it to support your claim that:
Therefore, it is you who are claiming that feof is broken for use with binary files.
The thing is, you are right to say that testing for EOF when reading a binary file is incorrect, but that is because using those functions that could return EOF to signal end of file is incorrect when working with a binary file. The problem isn't the test for EOF; the problem is using the wrong function, hence whiteflags countered that the solution is to read the file correctly by using binary file I/O functions, in which case feof (not testing for EOF) can be used as needed.
EDIT:
Wait, actually, even if you are reading a binary file that contains a character with a byte that matches whatever the value of EOF is on the system, you should still be safe since EOF is negative and the per-character input functions only return unsigned char as ints... well, except in the very special case where the range of int is the same as the range of signed char, and the stars align in the conversion from unsigned char to int.
Last edited by laserlight; 09-30-2012 at 09:20 PM.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
I got "can break feof()" from whiteflags post #20 "If the content of a file can break feof() then your implementation is broken". I think that I misread that.
I was initially agreeing with whiteflags and refering to oogabooga's post #11 and his use of getchar == EOF asking them to consider a binary file input
I stand by my claim that I didn't say that feof() would break from a files input, because I do not believe that - I couldn't find where someone could get that from the things that I posted.
Fact - Beethoven wrote his first symphony in C
Read closer, I never made such a comparison in my example code.I was initially agreeing with whiteflags and refering to oogabooga's post #11 and his use of getchar == EOF asking them to consider a binary file input
Furthermore, oogabooga didn't say anything that I necessarily disagree with. His opinion is that the usual file reading idiom is better, because it will stop the loop in the case of errors. My objection to that is at least as far as my code is concerned a valid file handle is all that is necessary, and I tried to cover all my bases when I said that the file has to be locked to greatly diminish the chance of errors that ferror() will care about. But he is still absolutely correct.
If anyone was morbidly curious, please consider the following. In glibc, feof() comes down to this bit of magic:
Drill down for yourself here. Cross Reference: /glibc/libio/feof.cCode:866#ifdef IO_DEBUG 867# define CHECK_FILE(FILE, RET) \ 868 if ((FILE) == NULL) { MAYBE_SET_EINVAL; return RET; } \ 869 else { COERCE_FILE(FILE); \ 870 if (((FILE)->_IO_file_flags & _IO_MAGIC_MASK) != _IO_MAGIC) \ 871 { MAYBE_SET_EINVAL; return RET; }}
I apologize about the extra line numbering. (But it even says _IO_MAGIC doesn't it) You can clearly see the internal indicater being tested. Well anyway, I'm sorry I cannot guarantee that all feof() implementations are exactly this, but it would seem against the design rationale to do any more than what is absolutely required.
The reason that oogabooga is correct may be obvious but if you are doing anything more complicated than reading text, like formatting input, then the flags for a bad state could be set, by say, scanf(). But chances are, the function that you are using has it's own facilities to tell you something went tits up.
What whiteflags means is that if the contents of a file can cause feof to be broken -- as in report the end of file status incorrectly -- then that test input proves that the given implementation of feof is broken, i.e., your standard library implementation would have a bug that needs to be fixed.
I think you did not realise that whiteflags' post #16 asked a rhetorical question. whiteflags wasn't asking how to read a binary file correctly with binary file I/O functions; whiteflags was posing a question that mimicked your own to get you to realise that there were binary file I/O functions for which your concerns about EOF with binary files don't matter at all, e.g., because the feof function might be used instead. I guess that you took the question literally, and thus quoted something that supports whiteflags' point, as if it supported your own point, but you believed that it would help answer whiteflags' question.
Right. Do you understand now that binary file input is not a problem here?
Look up a C++ Reference and learn How To Ask Questions The Smart Way
See comments in quote
Fact - Beethoven wrote his first symphony in C
Right, but whiteflags did not state that.
I think that you were arguing that "testing the returned value for EOF is not always the best way of determining when you have arrived at the end of a file" because you thought that "if your binary file is full of integers and one of the is the EOF character", there could be a problem. One thing that I suspect you missed is that fread does not return EOF to signal end of file.
A problem for what? You need to be specific.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
Let's say, getc() from a binary file. But you have already clarified that for me.A problem for what? You need to be specific.
Fact - Beethoven wrote his first symphony in C
