青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

行進(jìn)中開(kāi)火

C++夜未眠

MFC中一個(gè)危險(xiǎn)的Bug

 

上次說(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)提示。程序本身,是幾年前公司的其他人寫(xiě)的。里面有涉及到文件讀寫(xiě)的地方,有很多地方,用了MFC中自帶的文件讀寫(xiě)類CStdioFile。

CStdioFile這個(gè)文件讀寫(xiě)類,估計(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開(kāi)發(fā)的時(shí)候,盡量避免使用ReadString,或者在使用中,多判斷一步讀取出來(lái)的CString長(zhǎng)度。避開(kāi)這個(gè)Bug。

posted on 2010-03-26 22:15 Jakcie 閱讀(2301) 評(píng)論(4)  編輯 收藏 引用 所屬分類: C++ & CWindows & MFC

評(píng)論

# re: MFC中一個(gè)危險(xiǎn)的Bug 2010-03-27 22:16 陳梓瀚(vczh)

解決方法應(yīng)該是避免使用VC6進(jìn)行開(kāi)發(fā)。  回復(fù)  更多評(píng)論   

# re: MFC中一個(gè)危險(xiǎn)的Bug 2010-03-27 23:47 Jakcie

的確應(yīng)該避免用VC6開(kāi)發(fā)。但使用VC6的人,還是不少啊。  回復(fù)  更多評(píng)論   

# re: MFC中一個(gè)危險(xiǎn)的Bug 2010-03-28 11:17 唐風(fēng)

1. 遺留代碼不可替代
2. 升級(jí)開(kāi)發(fā)環(huán)境的預(yù)算和必要性
3. 有決策權(quán)開(kāi)發(fā)人員的“技術(shù)慣性”
使得VC6到現(xiàn)在還這么有“生命”力。感覺(jué)就像IE6一樣,哈哈,有種種的不好,可偏還是有那么多用戶。

反正我是等VS2010出來(lái)就準(zhǔn)備XX的,嘿嘿。

  回復(fù)  更多評(píng)論   

# re: MFC中一個(gè)危險(xiǎn)的Bug 2010-03-28 16:08 Jakcie

是啊。尤其是像這種遺留代碼,的確是沒(méi)有辦法。

好在現(xiàn)在公司的環(huán)境,基本都是VS2005. VS2010,估計(jì)短時(shí)間內(nèi)用不上。  回復(fù)  更多評(píng)論   

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            一本色道久久综合亚洲精品婷婷 | 国产亚洲综合性久久久影院| 欧美人成网站| 欧美金8天国| 欧美日韩免费观看一区三区| 欧美午夜美女看片| 亚洲精品在线观看免费| 日韩亚洲视频| 香蕉久久夜色精品国产| 久久综合久久美利坚合众国| 欧美理论电影网| 国产精品一卡| 亚洲黄一区二区| 中文欧美在线视频| 欧美一区二区三区免费视| 久久久久se| 亚洲人成网站999久久久综合| 亚洲品质自拍| 午夜一区在线| 欧美国产日韩在线| 国产美女高潮久久白浆| 亚洲国产精品黑人久久久| 一区二区三区福利| 久久综合婷婷| 日韩亚洲精品在线| 久久久五月婷婷| 欧美三级韩国三级日本三斤| 在线播放日韩专区| 亚洲一区二区视频| 美女国内精品自产拍在线播放| 99国内精品久久| 久久久国产视频91| 国产精品永久免费视频| 亚洲卡通欧美制服中文| 久久香蕉国产线看观看网| 亚洲免费观看高清在线观看| 久久免费午夜影院| 国产亚洲精品福利| 亚洲一区欧美激情| 亚洲韩国一区二区三区| 久久久人成影片一区二区三区观看| 国产精品电影在线观看| 一本色道久久综合狠狠躁篇的优点| 久久影视精品| 欧美一区激情| 国产精品日本一区二区| 亚洲午夜精品一区二区| 亚洲精品视频在线观看免费| 免播放器亚洲一区| 1024亚洲| 欧美国产先锋| 欧美成人一品| 91久久在线观看| 欧美激情在线观看| 欧美成人第一页| 亚洲精品国产精品乱码不99| 欧美激情1区| 欧美a级一区| 亚洲人体1000| 亚洲人成绝费网站色www| 欧美韩日视频| 亚洲色无码播放| 一区二区三区四区五区精品| 国产精品久久久久久久浪潮网站| 亚洲午夜影视影院在线观看| 久久精品国产亚洲aⅴ| 亚洲在线1234| 国内揄拍国内精品少妇国语| 免费视频最近日韩| 欧美激情国产高清| 亚洲一品av免费观看| 亚洲自拍偷拍视频| 狠狠色丁香久久综合频道| 男女激情久久| 欧美日韩国产一中文字不卡| 午夜精品美女自拍福到在线| 欧美一区三区三区高中清蜜桃| 国内一区二区三区| 亚洲国产综合在线看不卡| 欧美系列亚洲系列| 久久久久久999| 欧美激情视频免费观看| 亚洲欧美中文字幕| 久久精品卡一| 夜夜嗨av一区二区三区| 亚洲专区欧美专区| 亚洲国产精品悠悠久久琪琪| 99精品欧美一区二区三区综合在线 | 国产精品黄色在线观看| 久久精品一二三区| 美女脱光内衣内裤视频久久网站| 一区二区av在线| 欧美一级视频免费在线观看| 亚洲三级视频| 欧美在线一区二区| av成人老司机| 久久久www免费人成黑人精品 | 亚洲综合第一页| 影音先锋久久| 中文在线资源观看网站视频免费不卡 | 亚洲国产视频a| 国产区日韩欧美| 91久久精品一区| 国产亚洲在线| 亚洲在线免费视频| 99精品视频免费观看视频| 久久国产精品99精品国产| 一区二区三区免费看| 久久夜色精品| 久久久久成人精品| 国产精品日韩一区二区| 亚洲欧洲一二三| 狠狠爱综合网| 小处雏高清一区二区三区| 亚洲伊人网站| 欧美日韩精品| 亚洲国产精品久久久久秋霞蜜臀| 国产亚洲va综合人人澡精品| 亚洲美女免费视频| 亚洲精品乱码久久久久久| 洋洋av久久久久久久一区| 亚洲精品少妇网址| 久久久久免费观看| 欧美在线一二三四区| 欧美三级韩国三级日本三斤| 亚洲第一中文字幕| 亚洲人在线视频| 久久综合一区| 欧美不卡福利| 亚洲国产精品va在线看黑人| 久久亚洲精品伦理| 久久视频在线免费观看| 狠狠色伊人亚洲综合成人| 午夜免费日韩视频| 欧美主播一区二区三区美女 久久精品人| 欧美日韩999| 99热这里只有精品8| 亚洲少妇在线| 国产精品久久久免费| 亚洲图片在区色| 久久精品国产在热久久| 韩国在线视频一区| 久久久久久91香蕉国产| 狂野欧美激情性xxxx| 国语精品中文字幕| 久久天天躁夜夜躁狠狠躁2022| 欧美xxx成人| 99在线观看免费视频精品观看| 欧美欧美全黄| 亚洲私拍自拍| 久久婷婷激情| 亚洲精品黄色| 国产精品国产三级国产普通话蜜臀| 亚洲神马久久| 久久综合色天天久久综合图片| 91久久精品一区| 欧美性大战久久久久| 西西人体一区二区| 亚洲第一精品福利| 亚洲女同在线| 禁久久精品乱码| 欧美日韩精品伦理作品在线免费观看| 一区二区三区精密机械公司 | 亚洲欧洲日本mm| 午夜精品免费在线| 亚洲电影视频在线| 欧美天堂亚洲电影院在线观看| 欧美一区日本一区韩国一区| 亚洲高清中文字幕| 欧美在线免费看| 日韩手机在线导航| 国产日韩在线一区| 欧美极品一区| 久久婷婷影院| 亚洲小说欧美另类社区| 久久午夜激情| 亚洲综合色在线| 亚洲日本无吗高清不卡| 国产乱码精品一区二区三区不卡 | 亚洲香蕉成视频在线观看| 美女网站在线免费欧美精品| 亚洲性图久久| 亚洲人妖在线| 曰本成人黄色| 国产亚洲综合性久久久影院| 欧美精品免费看| 欧美一区二粉嫩精品国产一线天| 久久一日本道色综合久久| 亚洲视频精品在线| 亚洲国产免费| 久久嫩草精品久久久久| 亚洲伊人网站| 亚洲精品日韩在线观看| 在线观看日韩欧美| 国产一区二区三区在线播放免费观看 | 一区二区三区黄色| ●精品国产综合乱码久久久久| 国产欧美日本在线| 国产精品二区二区三区| 欧美日韩黄色一区二区|