is this a good way to test EOF ?
Code:int has_more_packets(FILE *inFile_bin) { FILE *temp = inFile_bin; fseek (temp, 0, SEEK_END); if(inFile_bin == temp) { return 0; } return 1; }
is this a good way to test EOF ?
Code:int has_more_packets(FILE *inFile_bin) { FILE *temp = inFile_bin; fseek (temp, 0, SEEK_END); if(inFile_bin == temp) { return 0; } return 1; }
No!
Ah, you want me to explain WHY it's not good too?
There are several problems, but the most obvious one is that you make a copy of a FILE *, then compare it with the original. This will ALWAYS match, because you are comparing the same address - both pointers will have ALWAYS have the same value [unless you actually assign one of them to something else].
You seem to have the misconception that a FILE * changes when you seek the file - this changes [possibly] some internal data in the structure that a FILE * points at, not the actual pointer itself.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
but if i use ftell on temp and inFile_bin and I compare that. whould that be ok ?
Well, sort of. The only problem is that temp and in_file are exactly the same FILE object - they are two pointers, but they are pointing to the same thing.
Consider:
You are doing the same thing, the only difference is that your pointer is pointing to a datastructure that is called FILE [and that we don't know what it looks like, because you shouldn't be able to access it from your code].Code:int x = 7; int *p = &x; int *q = p; /// What does q point at now? x, right? So if we do *q = 9; /// Now, x = 9, so *p = 9.
So, as a consequence, you have now moved the file-pointer to the end of the file, and when you return, you WILL be at the end of file. You can of course fix that up by setting the file-pointer to the position ftell told you. You also don't need to have a second FILE * variable, it is just a waste of time, space and adds confusion to the code.
There are perfectly adequate ways to tell that you have reached end of file in normal C functions, so unless you are tasked with "how can you determine that you are at the end of file without using any of the standard techniques" I would recommend that you use one of those - the common ones are:
1. Try to read some data, and if it fails [either reads nothing, or less than you "expected"], you have reached end of file.
2. check feof() when you have just read something from the file, and break the input if it returns "true".
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
the thing is that i am trying to control a loop with that function and i've read that feof() is not that adequate to do that
Yes, that's [sort of] correct. You don't want to do "while (!feof(...))" - but that doesn't mean that you can't use feof() to check if you reached end of file - the problem isn't that feof() itself is broken, but rather that it's not true UNTIL YOU HAVE READ TO THE END OF FILE, and the classical symptom of that is that "you get one more read than you wanted", and if you don't check for end-of-file AFTER the reading of data, you may add some "rubbish" when you couldn't read another item fo data.
I doubt that comparing the current fiel-pointer with the end of the file is really an adequate way of solving the problem unless you really know something about the particular circumstances in the file.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
In other words, what you should be doing is testing the return result of whatever file reading function you're using, not trying to write a replacement for feof().
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.