上次說(shuō)日本海嘯警報(bào)的時(shí)候，程序出錯(cuò)。在解析代碼的時(shí)候，發(fā)現(xiàn)了MFC中的一個(gè)Bug。
一。問(wèn)題的產(chǎn)生。
這個(gè)程序，用來(lái)處理日本各種天氣預(yù)報(bào)數(shù)據(jù)，包括災(zāi)害的預(yù)報(bào)。如果地震，臺(tái)風(fēng)之類的自然災(zāi)害到來(lái)，程序會(huì)把預(yù)報(bào)數(shù)據(jù)進(jìn)行處理，生成相應(yīng)的警報(bào)信息，并在電視上面顯示滾動(dòng)的字幕來(lái)提示。程序本身，是幾年前公司的其他人寫的。里面有涉及到文件讀寫的地方，有很多地方，用了MFC中自帶的文件讀寫類CStdioFile。
CStdioFile這個(gè)文件讀寫類，估計(jì)大家都不陌生。這個(gè)類的父類，是CFile類。CStdioFile類本身的功能也很簡(jiǎn)單。CStdioFile類有一個(gè)成員函數(shù)是ReadString，函數(shù)的定義如下：
virtual LPTSTR ReadString(__out_ecount_z(nMax) LPTSTR lpsz, __in UINT nMax);
virtual BOOL ReadString(CString& rString);
MSDN定義如下
http://msdn.microsoft.com/library/x5t0zfyf(VS.80).aspx：
BOOL ReadString(CString& rString);
throw( CFileException );
Return Value
A pointer to the buffer containing the text data. NULL if end-of-file was reached without reading any data; or if boolean, FALSE if end-of-file was reached without reading any data.
ReadString函數(shù)能直接讀取文本中的一行數(shù)據(jù)到CString中，很方便。讀到文件結(jié)尾，沒(méi)有讀出任何數(shù)據(jù)的時(shí)候，返回FALSE。很簡(jiǎn)單的函數(shù)，但恰恰是這個(gè)函數(shù)有Bug。
程序在處理數(shù)據(jù)的時(shí)候，會(huì)生成一些臨時(shí)文件，然后會(huì)讀取這些臨時(shí)文件中的數(shù)據(jù)，讀取操作，正是用的CStdioFile的ReadString函數(shù)。讀取流程很簡(jiǎn)單：
while(dFile.ReadString(Str_temp))
{
doSomething();
}
當(dāng)時(shí)的現(xiàn)象為，讀取到最后一行，總是直接返回FALSE，怎么也讀不出最后一行來(lái)。看了看文件的最后一行，包含2176個(gè)字符的數(shù)據(jù)，沒(méi)有換行符。沒(méi)有任何異常啊。當(dāng)時(shí)沒(méi)想到是MFC的Bug，因?yàn)橐郧坝羞@樣那樣的毛病，多數(shù)是預(yù)報(bào)數(shù)據(jù)本身有問(wèn)題，所以這次也是先分析數(shù)據(jù)了。分析來(lái)分析去，沒(méi)發(fā)現(xiàn)這次的數(shù)據(jù)有什么異常。后來(lái)發(fā)現(xiàn)如果最后一行的文件不是2176個(gè)字符，就能正常讀出來(lái)。奇了怪了，2176也不是什么特殊長(zhǎng)度啊。實(shí)驗(yàn)了幾次后，覺(jué)的是在不對(duì)勁。莫非是MFC的Bug？
二。發(fā)現(xiàn)問(wèn)題所在
決定看看MFC的代碼再說(shuō)。做了個(gè)簡(jiǎn)單的測(cè)試程序，跟到MFC代碼里一看，果然是MFC的問(wèn)題！測(cè)試代碼如下：
CStdioFile dFile;
dFile.Open("text.txt",CFile::modeRead);
CString str;
while (dFile.ReadString(str) != FALSE )
{
printf("%s", str);
}
dFile.Close();
測(cè)試代碼很簡(jiǎn)單，讀text.txt文件中的每一行，然后打印出來(lái)。還是2176個(gè)字符就不行。確定了不是數(shù)據(jù)的問(wèn)題，就是MFC代碼本身的Bug。
MFC的ReadString代碼如下：（中文是我加的注釋）
BOOL CStdioFile::ReadString(CString& rString)
{
ASSERT_VALID(this);
rString = &afxChNil; // empty string without deallocating
const int nMaxSize = 128; //臨時(shí)字符串的長(zhǎng)度
LPTSTR lpsz = rString.GetBuffer(nMaxSize); //保存每次讀取到的字符串到CString中
LPTSTR lpszResult; //指向每次讀到的字符串
int nLen = 0;
for (;;)
{
lpszResult = _fgetts(lpsz, nMaxSize+1, m_pStream); //讀取操作
rString.ReleaseBuffer();
// handle error/eof case
if (lpszResult == NULL && !feof(m_pStream))
{
clearerr(m_pStream);
AfxThrowFileException(CFileException::generic, _doserrno,
m_strFileName);
}
// if string is read completely or EOF
if (lpszResult == NULL ||
(nLen = lstrlen(lpsz)) < nMaxSize ||
lpsz[nLen-1] == '\n')
break;
nLen = rString.GetLength();
lpsz = rString.GetBuffer(nMaxSize + nLen) + nLen; //位置后移
}
// remove '\n' from end of string if present
lpsz = rString.GetBuffer(0);
nLen = rString.GetLength();
if (nLen != 0 && lpsz[nLen-1] == '\n') // 最后結(jié)果中，去掉回車符
rString.GetBufferSetLength(nLen-1);
return lpszResult != NULL; // 這里就是Bug的關(guān)鍵。返回值不對(duì)！
}
可以看到，ReadString的底層，是用fgets來(lái)讀取文件的。在內(nèi)部，每次讀取128個(gè)字符到CString中，然后位置后移，反復(fù)讀取128個(gè)字符，直到遇到回車符或者文件結(jié)束。最后把回車符去掉，返回一個(gè)CString。其中，lpszResult也指向每次讀出的字符串。
這里就看出問(wèn)題所在了，2176個(gè)字符，正好是128的17倍！也就是說(shuō)，只要文件最后一行是128倍數(shù)個(gè)字符，就一定會(huì)返回FALSE。
為什么會(huì)這樣呢，因?yàn)镽eadString在每次讀取128個(gè)字符的時(shí)候，用lpszResult指向讀取到的字符串。如果讀滿了128個(gè)字符，就繼續(xù)讀，如果讀到的字符不夠128個(gè)，那么就結(jié)束讀取。
當(dāng)一行數(shù)據(jù)正好為128的倍數(shù)，又沒(méi)有回車符的時(shí)候，會(huì)發(fā)生什么呢？比如最后一行數(shù)據(jù)是128個(gè)，那么，讀一次128個(gè)字符，會(huì)繼續(xù)讀下一次，但是下一次的讀取，什么也沒(méi)有讀到，lpszResult就指向NULL，最后的返回值，是return lpszResult != NULL; 所以返回FALSE。
但之前讀到的128個(gè)字符，已經(jīng)在CString里面了。也就是說(shuō)實(shí)際上讀取已經(jīng)成功了，但還是返回了FALSE。返回值不恰當(dāng)！
Bug的描述：當(dāng)文件的最后一行數(shù)據(jù)，正好是128的倍數(shù)個(gè)字符的時(shí)候，用ReadString讀取，一定會(huì)返回FALSE。但實(shí)際上讀取是成功的，返回的CString中的數(shù)據(jù)是正確的！（VC6.0中存在這個(gè)Bug，VS2005中，沒(méi)有這個(gè)Bug）
這個(gè)Bug，只會(huì)影響到最后一行數(shù)據(jù)。因?yàn)槿绻袚Q行符的存在，lpszResult就不會(huì)為NULL。
三。解決方法
要解決這個(gè)問(wèn)題，也簡(jiǎn)單，修改一下判斷ReadString成功與否的語(yǔ)句：
while (dFile.ReadString(str) != FALSE || str.GetLength() != 0)
在返回FALSE的情況下，CString的長(zhǎng)度不為0，就不算讀取失敗。或者這樣:
if(!dFile.ReadString(str) && str.GetLength() == 0)
在返回FALSE并且CString的長(zhǎng)度為0，則算讀取失敗，否則就是讀取成功。
這個(gè)程序，是用VC6.0做的，我有看了看VC2005中的代碼，發(fā)現(xiàn)這個(gè)Bug被修復(fù)了，代碼如下：
BOOL CStdioFile::ReadString(CString& rString)
{
ASSERT_VALID(this);
rString = _T(""); // empty string without deallocating
const int nMaxSize = 128;
LPTSTR lpsz = rString.GetBuffer(nMaxSize);
LPTSTR lpszResult;
int nLen = 0;
for (;;)
{
lpszResult = _fgetts(lpsz, nMaxSize+1, m_pStream);
rString.ReleaseBuffer();
// handle error/eof case
if (lpszResult == NULL && !feof(m_pStream))
{
Afx_clearerr_s(m_pStream);
AfxThrowFileException(CFileException::genericException, _doserrno,
m_strFileName);
}
// if string is read completely or EOF
if (lpszResult == NULL ||
(nLen = (int)lstrlen(lpsz)) < nMaxSize ||
lpsz[nLen-1] == '\n')
break;
nLen = rString.GetLength();
lpsz = rString.GetBuffer(nMaxSize + nLen) + nLen;
}
// remove '\n' from end of string if present
lpsz = rString.GetBuffer(0);
nLen = rString.GetLength();
if (nLen != 0 && lpsz[nLen-1] == '\n')
rString.GetBufferSetLength(nLen-1);
return nLen != 0; //返回值變了！
}
我們看到，VC2005中，讀取部分的代碼與VC6.0中的代碼完全一樣。不一樣的地方只是返回值的部分。VC2005的ReadString中，返回值為
return nLen != 0;
也就是說(shuō)，只要讀出的CString的長(zhǎng)度不為0就為讀取成功。與我修改后的方法完全一致。就這樣向客戶解釋，然后修改了。悲劇的是，幾年前所有程序中所有使用ReadString函數(shù)的地方，都要進(jìn)行修改。。。
MFC的這個(gè)Bug比較隱蔽，平常不容易發(fā)現(xiàn)，但一旦遇到特殊長(zhǎng)度的數(shù)據(jù)，就會(huì)表現(xiàn)異常。所以，在用VC6.0開發(fā)的時(shí)候，盡量避免使用ReadString，或者在使用中，多判斷一步讀取出來(lái)的CString長(zhǎng)度。避開這個(gè)Bug。