4

I'm programming C on Windows(system language is Japanese), and I have a problem about EOF of binary and ascii files.

I asked this question last week, a kind guy helped me, but I still can't really understand how the program works when reading a binary or an ascii file.

I did the following test:

Test1:

int oneChar;
iFile = fopen("myFile.tar.gz", "rb");
while ((oneChar = fgetc(iFile)) != EOF) {
        printf("%d ", oneChar);
}

Test2:

int oneChar;
iFile = fopen("myFile.tar.gz", "r");
while ((oneChar = fgetc(iFile)) != EOF) {
        printf("%d ", oneChar);
}

In the test1 case, things worked perfectly for both binary and ascii files. But in test2, program stopped reading when it encountered 0x1A in a binary file. (Does this mean that 1A == EOF?) ASCII table tells me that 1A is a control character called substitute (whatever that means...) And when I printf("%d", EOF), however, it gave me -1...

I also found this question which tells me that the OS knows exactly where a file ends, so I don't really need to find EOF in the file, because EOF is out of the range of a byte (what about 1A?)

Can someone clear things up a little for me? Thanks in advance.

Community
  • 1
  • 1
Eumaa
  • 971
  • 2
  • 15
  • 38
  • Here are some explanations about the char you encountered 0x1A: https://en.wikipedia.org/wiki/Substitute_character – Guillaume George Jan 14 '16 at 02:58
  • How did you determine that it stopped reading at the 0x1A? If it printed the number 26 (0x1A) at the end of its output, that means it read that byte normally, but then got EOF when trying to read whatever came *after* it. If 0x1A were EOF, you wouldn't see that value in the output at all. – Wyzard Jan 14 '16 at 02:58
  • I used system("PAUSE") at the end. so in Test1 case, it printed like: 1 23 43 ... 150 26 46 ... press any key to continue, but in Test2, it printed like: 1 23 43 ... 150 press any key to continue. In Test1, 26 is printed, but in Test2, the number before 26, 150, is the last character it printed. So I think in Test2, 26 makes (oneChar = fgetc(iFile)) != EOF a false statement – Eumaa Jan 14 '16 at 03:13

4 Answers4

8

This is a Windows-specific trick for text files: SUB character, which is represented by Ctrl+Z sequence, is interpreted as EOF by fgetc. You do not have to have 1A in your text file in order to get an EOF back from fgetc, though: once you reach the actual end of file, EOF would be returned.

The standard does not define 1A as the char value to represent an EOF. The constant for EOF is of type int, with a negative value outside the range of unsigned char. In fact, the reason why fgetc returns an int, not char, is to let it return a special value for EOF.

Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
  • Does this mean using some other reading method (getchar(), for example) instead of fgetc() can solve the problem? – Eumaa Jan 14 '16 at 03:18
  • 1
    @CHEN Using `getchar` is not going to fix this problem, but opening the file in binary mode will (of course, you know this already through your experiment). – Sergey Kalinichenko Jan 14 '16 at 08:26
5

The convention of ending a file with Ctrl-Z originated with CP/M, a very old operating system for 8080/Z80 microcomputers. Its file system did not keep track of file sizes down to the byte level, only to the 128-byte sector level, so there needed to be another way to mark the end-of-file.

Microsoft's DOS was made to be as compatible with CP/M as possible, so it kept the convention when reading text files. By this time the file size was kept by the file system so it wasn't strictly necessary, just retained for backward compatibility.

This convention has persisted to the present day in the C and C++ libraries for Windows; when you open a file in text mode, every character is checked for Ctrl-Z and the end-of-file flag is set if it's detected. You're seeing the effects of backwards compatibility taken to an extreme, back to systems that are almost 40 years old.

Mark Ransom
  • 299,747
  • 42
  • 398
  • 622
  • "originated" with CP/M? Certainly CP/M was an early user of Ctrl-Z as EOF, but first? Suppose I'd need to look up some Neolithic tablet to show otherwise. – chux - Reinstate Monica Jan 14 '16 at 14:14
  • @chux you're right, according to [Wikipedia](https://en.wikipedia.org/wiki/Control-Z) it originated at DEC and was *copied* by CP/M. CP/M was certainly the reason it that DOS had it. – Mark Ransom Jan 14 '16 at 17:26
  • The wiki mentioned DEC _used_ it - perhaps it _originated_ even earlier in the long lost mists of the computer lore. IAC `Ctrl-Z` looks like a good programmer [epitaph](https://en.wikipedia.org/wiki/Epitaph). – chux - Reinstate Monica Jan 14 '16 at 17:40
0

Found a terrific article that answers all the question! https://latedev.wordpress.com/2012/12/04/all-about-eof/

Eumaa
  • 971
  • 2
  • 15
  • 38
0

EOF in text files is usually character 0x1A or ASCII 26 if you will.