Hi I am coding on win7 in C.
If I'm right win7 is not counting EOF(end of file) in total memory usage of text file(.txt)?
E.g., if I have simple text file with 3 characters:
a
b
c
this file is stored on disk as:
a\r\nb\r\ncEOF
that's total 8 bytes, when i right click that file and hit properties I get 7 bytes, why?
There is no actual EOF character in your file*. EOF is just a value that read functions return to tell you when the input is over. EDIT: This is why functions like getchar actually return an int, to hold all possible char values and why you must declare your variables that store the result of getchar as ints. Read this: http://c-faq.com/stdio/getcharc.html.
Some file systems may implement an "EOF character" to mark the end of the file, some may not. Some may simply keep track of the length and whether you've read all the bytes or not. C does not care about what kind of file system you're using, thus it won't care if there's an actual EOF character or not. The OS will tell whatever read functions you're using that it reached the end of the file. Even if a file system did use an EOF character, it would probably not count it in the file size, since it is metadata, not "actual" file data. You only put 7 bytes in the file, so that's all there is. If the OS/file system needs extra bytes to track other info about your file, it's not part of the file size.
Last edited by anduril462; 03-16-2012 at 04:10 PM.
It's easy to prove that this is not the case. Create a text file, and somewhere in the middle of it insert a ^Z character (byte with value 0x1A). Then write a little C program that opens the file in text mode and reads from the file. At least on Microsoft's runtime, as soon as it hits that ^Z character it will treat it as the end of the file. The only way to read past it is to open the file in binary mode.C does not care about what kind of file system you're using, thus it won't care if there's an actual EOF character or not.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Thanks I see... Can fread() go out of the bound of the file and potentially SegFault, or it stops when EOF is reached?
fread wont read past the end of file. If you try to read more data than there is left in the file, it will return a short item count, i.e. it will return how many things it actually read, instead of how many you asked for. For example, if you try to read 10 bytes, and fread returns 2, you need to handle that. Note that fread doesn't distinguish between an error and end of file, so use feof() and ferror() to check what happened. Read the documentation for details: fread man page.
A call to fread can cause a seg fault however, if you aren't careful about where you store the data you read. If you store it in some buffer/array, and try to write past then end of that, or you're simply trying to store the data in an invalid pointer, you may cause a seg fault.
This is entirely OS/compiler specific (not the EOF character itself, but the text vs binary mode). BSD doesn't have a difference between text and binary modes. (fopen)Originally Posted by brewbuck
Quzah.
Last edited by quzah; 03-16-2012 at 08:26 PM.
Hope is the first step on the road to disappointment.
That is true of every Unix not just BSD. All *nixes treat a file as an unformatted stream of bytes.
Thanks, problem solved.
The fact that the modes even exist is evidence that you need to be prepared for them to be different. Thus portable code has to assume they are different, not that they are the same. Which means weird things can happen, such as an apparent EOF in the middle of a file, when opened in the wrong mode on Windows.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
That doesn't actually prove anything, other than the fact that Windows runtimes still have vestiges from CP/M, which MS-DOS was based off of*. My statement you were trying to refute, that C doesn't care whether there's an actual EOF character, was and is completely true, and is not disproved by your example in any way. C is ignorant of the underlying file system (part of the reason there's no standard C function to get file size, iterate through directory structures, etc). It simply asks the OS for data from the stream. The circumstances under which the OS reports end-of-file to the C library functions has absolutely nothing to do with C nor file mode, and everything to do with the file system. Furthermore, the OP's example made it pretty clear that the only thing he put in the file were some letters and newlines, no 0x1a character. You've been on this board long enough to know that many newbies have the misconception that there is some magical, universal EOF character stored at the end of every file on every computer system everywhere, and is what is returned by functions like getchar. More evidence of this misconception is the fact that the OP was asking why the "EOF character" was not reported in the file size when he examined the properties, i.e. he expected the mythical EOF character that wasn't there. The 0x1a byte, if present in a file, is counted as part of the file size, and doesn't cause the file system or OS to stop counting early (at least on NTFS -- I no longer have any FAT filesystems to check this on).
* Without doing way more research than I care to on this topic, that's the best I could do to trace the origin of this behavior.
