CStdioFile is broken in about 6 ways
Visual Studio 2005 SP1 is running on Windows XP SP2. A new project is
compiled using Unicode (the default). CString is Unicode.
CStdioFile::ReadString reads garbage.
CStdioFile infile;
CString infline;
CString inftmp;
if (!infile.Open(infname, CFile::modeRead | CFile::typeText)) return FALSE;
while (infile.ReadString(inftmp)) {
infline = inftmp;
while (inftmp.Right(1) != _T('\r')) {
if (!infile.ReadString(inftmp)) return FALSE;
infline += inftmp;
}
// processing omitted
The input file is ANSI. The input file is tab separated text. Complete
lines are separated by carriage return-linefeed pairs. Fields are separated
by tab characters but that part of it works. A single field might contain
multiple substrings separated by bare linefeeds without carriage returns.
Has anyone in Microsoft ever heard of an Excel program that might create a
file in this format?
http://msdn2.microsoft.com/en-us/library/x5t0zfyf(VS.80).aspx
CStdioFile::ReadString
Reading is stopped by the first newline character. If, in that case, fewer
than nMax-1 characters have been read, a newline character is stored in
the buffer. A null character ('\0') is appended in either case.
CFile::Read is also available for text-mode input, but it does not
terminate on a carriage return-linefeed pair.
Note
The CString version of this function removes the '\n' if present; the
LPTSTR version does not.
Problem 1.
Fine, let it terminate when it hits the first carriage return-linefeed pair,
and not terminate when it hits a bare linefeed. Oops, it doesn't work that
way. A "newline character" doesn't mean a "carriage return-linefeed pair",
it means any "linefeed character". Fair enough. That's why I coded an
extra loop the way I did.
Problem 2.
Fine, let it terminate when it hits the first linefeed character, and let it
remove the '\n'. When my extra loop sees the remaining '\r', it will
recognize the end of the line. Oops, it doesn't work that way. A "newline
character" or "the '\n'" means a carriage return-linefeed pair. Fair
enough. My extra loop needs to be removed.
Problem 3.
Problem 1 vs. Problem 2. OK. "Consistency is the last refuge of an
uncreative person." Let no one accuse Microsoft of failing to innovate.
Problem 4.
If I try reading binary instead of text, then the CString reads complete
garbage. Two single-byte ANSI characters turn into one garbage Unicode
character or maybe just plain garbage. One double-byte ANSI character turns
into one garbage Unicode character or maybe just plain garbage. One
single-byte ANSI character plus a lead byte of a double-byte ANSI character
.... etc. OK, I give up with binary and revert to text.
Problem 5.
If I read enough of a line in order to temporarily evade problems 1, 2, and
3, then let's see what the text looks like. Well, that's broken too. One
single-byte ANSI character turns into one Unicode character and it's
correct, wow! One double-byte ANSI character turns into some number of
garbage Unicode characters (I didn't count them) or maybe just plain
garbage. Hello Microsoft, has anyone heard of the MultiByteToWideChar API?
Any reason you couldn't call that function when reading a text file? Any
reason why you had to make CStdioFile::ReadString work on foreign characters
but get all b0rked when reading text in the same language as Visual Studio
2005 SP1 and Windows XP SP2 and MFC?
Problem 6 (minor).
Idiot me, I wanted to see if there was any other way to open the text file
before giving up and using APIs to read it byte by byte. I went to page
http://msdn2.microsoft.com/en-us/library/default.aspx
and typed
CFile::CFile
into the search box. Yeah right Microsoft, surely I really did mean:
chile chile site lab msdn microsoft
After all, the Japanese versions of Visual Studio 2005 SP1 and Windows XP
SP2 and MFC are only b0rked in Japan; they probably work in Chile. Oh, and
how nice of Microsoft to find a page the constructor CFile::CFile, after
four other methods which are obviously more highly relevant.