How to handle unexpected file termination with ASCII code 0x1a

In Windows, when writing programs with file operations, you may encounter a strange phenomenon. In the process of reading a file in text format, the feof () function is unexpectedly true before the end of the file. This is surprising, and it is hard to find the cause for the moment. In fact, this is an ascii code 0x1a. Run the following program:

Int main (void)
{
Int I;
Unsigned char C;
File * FP;
Fp = fopen ("test. dat", "W ");
Fprintf (FP, "ABC/x1a Def ");
Fclose (FP );
Fp = fopen ("test. dat", "R ");
For (I = 0; I <= 7; ++ I)
{
Fread (& C, sizeof (char), 1, FP );
Printf ("% 02x feof = % d/N", C, feof (FP ));
}
Fclose (FP );
Return 0;
}

The running result is:

61 feof = 0
62 feof = 0
63 feof = 0
63 feof = 16
63 feof = 16
63 feof = 16
63 feof = 16
63 feof = 16

From the above results, we can see that feof is true when the fourth character is 0x1a. This phenomenon only exists in Windows, and does not exist in Unix/Linux. Why?

0x1a represents EOF in ASCII code. In the past, EOF was used as a file terminator in Unix/Linux. Microsoft inherited this tradition, it also uses EOF as the file Terminator. However, some information in the author's hand shows that Microsoft has abandoned this approach since dos5.0. However, this problem exists in dos6.22, windows3.1, windows3.2, Windows9X, windows2k, XP, and 2003. At the same time, the problem is caused by the system or database function, which still needs to be further verified. Because there is no source code, it cannot be confirmed. If any friend has such information, he hopes to share it. On the other hand, since all mainstream compilers in DOS/Windows, such as Vc, BCB, GCC, tc2.0, and bc3.1, are the same results, I prefer this is caused by the system.

So is this 0x1a phenomenon compliant with the standard? C89/c99 defines the file stream in two ways:

7.19.2 streams

A text stream is an ordered sequence of characters composed into lines, each line consisting of zero or more characters plus a terminating New-line character. whether the last line requires a terminating New-line character is implementation-defined. characters may have to be added, altered, or deleted on input and output to conform to differing conventions for representing text in the host environment. thus, there need not be a one-to-one corresponsor between the characters in a stream and those in the external representation.

A binary stream is an ordered sequence of characters that can transparently record internal data. data read in from a binary stream shall compare equal to the data that were earlier written out to that stream, under the same implementation.

Description: The text mode can be used to add, replace, and delete characters in the input and output files. Is 0x1a a problem in these three cases? I don't think it is because it logically truncates the file, not just adding, replacing, or deleting characters. If this is confirmed to be illegal, library functions have the responsibility to correct it, whether it is a library function or a system.

How can this problem be solved? In fact, one of the solutions has been provided by the standard. Because the input and output in binary mode are one-to-one correspondence, and the characters do not change, this problem will not occur if binary is used for reading, it turns out that it is okay, but there is a little trouble. Because/N is converted to/R/N in windows, the conversion must be sorted and restored during binary reading, this will increase the complexity of the Code, which is annoying. Therefore, I try to find better answers in low-level functions, but it is disappointing that the low-level functions of several mainstream compilers do not convert/R/n even in the text mode, because the behavior of low-level functions has nothing to do with the standard, if the low-level functions of the compiler restore/R/N, It is a better solution than the binary method.

However, the above methods are not perfect in any case. Does this mean that the text method of Windows has no significance? This is frustrating. If you have any in-depth research, you are welcome to discuss it together.