上次说日本海啸警报的时候，程序出错。在解析代码的时候，发现了MFC中的一个Bug。

一。问题的产生。

这个程序，用来处理日本各种天气预报数据，包括灾害的预报。如果地震，台风之类的自然灾害到来，程序会把预报数据进行处理，生成相应的警报信息，并在电视上面显示滚动的字幕来提示。程序本身，是几年前公司的其他人写的。里面有涉及到文件读写的地方，有很多地方，用了MFC中自带的文件读写类CStdioFile。

CStdioFile这个文件读写类，估计大家都不陌生。这个类的父类，是CFile类。CStdioFile类本身的功能也很简单。CStdioFile类有一个成员函数是ReadString，函数的定义如下：

    virtual LPTSTR ReadString(__out_ecount_z(nMax) LPTSTR lpsz, __in UINT nMax);
    virtual BOOL ReadString(CString& rString);

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函数能直接读取文本中的一行数据到CString中，很方便。读到文件结尾，没有读出任何数据的时候，返回FALSE。很简单的函数，但恰恰是这个函数有Bug。

程序在处理数据的时候，会生成一些临时文件，然后会读取这些临时文件中的数据，读取操作，正是用的CStdioFile的ReadString函数。读取流程很简单：

while(dFile.ReadString(Str_temp))
{
    doSomething();
}

当时的现象为，读取到最后一行，总是直接返回FALSE，怎么也读不出最后一行来。看了看文件的最后一行，包含2176个字符的数据，没有换行符。没有任何异常啊。当时没想到是MFC的Bug，因为以前有这样那样的毛病，多数是预报数据本身有问题，所以这次也是先分析数据了。分析来分析去，没发现这次的数据有什么异常。后来发现如果最后一行的文件不是2176个字符，就能正常读出来。奇了怪了，2176也不是什么特殊长度啊。实验了几次后，觉的是在不对劲。莫非是MFC的Bug？

二。发现问题所在

决定看看MFC的代码再说。做了个简单的测试程序，跟到MFC代码里一看，果然是MFC的问题！测试代码如下：

    CStdioFile  dFile;
    dFile.Open("text.txt",CFile::modeRead);
    CString str;
    while (dFile.ReadString(str) != FALSE )
    {
        printf("%s", str);
    }
    dFile.Close();

测试代码很简单，读text.txt文件中的每一行，然后打印出来。还是2176个字符就不行。确定了不是数据的问题，就是MFC代码本身的Bug。

MFC的ReadString代码如下：（中文是我加的注释）

BOOL CStdioFile::ReadString(CString& rString)
{
    ASSERT_VALID(this);
    rString = &afxChNil;    // empty string without deallocating
    const int nMaxSize = 128;  //临时字符串的长度
    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') // 最后结果中，去掉回车符
        rString.GetBufferSetLength(nLen-1); 
    return lpszResult != NULL;  // 这里就是Bug的关键。返回值不对！
}

可以看到，ReadString的底层，是用fgets来读取文件的。在内部，每次读取128个字符到CString中，然后位置后移，反复读取128个字符，直到遇到回车符或者文件结束。最后把回车符去掉，返回一个CString。其中，lpszResult也指向每次读出的字符串。

这里就看出问题所在了，2176个字符，正好是128的17倍！也就是说，只要文件最后一行是128倍数个字符，就一定会返回FALSE。

为什么会这样呢，因为ReadString在每次读取128个字符的时候，用lpszResult指向读取到的字符串。如果读满了128个字符，就继续读，如果读到的字符不够128个，那么就结束读取。

当一行数据正好为128的倍数，又没有回车符的时候，会发生什么呢？比如最后一行数据是128个，那么，读一次128个字符，会继续读下一次，但是下一次的读取，什么也没有读到，lpszResult就指向NULL，最后的返回值，是return lpszResult != NULL; 所以返回FALSE。

但之前读到的128个字符，已经在CString里面了。也就是说实际上读取已经成功了，但还是返回了FALSE。返回值不恰当！

Bug的描述：当文件的最后一行数据，正好是128的倍数个字符的时候，用ReadString读取，一定会返回FALSE。但实际上读取是成功的，返回的CString中的数据是正确的！（VC6.0中存在这个Bug，VS2005中，没有这个Bug）

这个Bug，只会影响到最后一行数据。因为如果有换行符的存在，lpszResult就不会为NULL。

三。解决方法

要解决这个问题，也简单，修改一下判断ReadString成功与否的语句：

while (dFile.ReadString(str) != FALSE || str.GetLength() != 0)

在返回FALSE的情况下，CString的长度不为0，就不算读取失败。或者这样:

if(!dFile.ReadString(str) && str.GetLength() == 0)

在返回FALSE并且CString的长度为0，则算读取失败，否则就是读取成功。

这个程序，是用VC6.0做的，我有看了看VC2005中的代码，发现这个Bug被修复了，代码如下：

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;

也就是说，只要读出的CString的长度不为0就为读取成功。与我修改后的方法完全一致。就这样向客户解释，然后修改了。悲剧的是，几年前所有程序中所有使用ReadString函数的地方，都要进行修改。。。

MFC的这个Bug比较隐蔽，平常不容易发现，但一旦遇到特殊长度的数据，就会表现异常。所以，在用VC6.0开发的时候，尽量避免使用ReadString，或者在使用中，多判断一步读取出来的CString长度。避开这个Bug。

1960年智利海域发生了9.5级（太恐怖了。。。）地震。引起了海啸，一直穿过整个太平洋，从南美，一直到东亚。日本，夏威夷，菲律宾都有200多人死亡。所以，这次8.8级地震，如果再来一次海啸，那可不得了啊。这次智利爆发的地震，引发了剧烈的海啸。如今，海啸的巨浪正在横过太平洋，直奔日本海岸而来。估计到达日本时，浪高依然可以达到10-20英尺。

日本全国都在紧急动员防范海啸，电视台在电视屏幕一角实时展示一幅日本地图，所有专家预测会遭到海啸袭击的地区都被标记出来，如今，从北海道 到冲绳，整个日本东海岸几乎都变成了一片红色。屏幕上方则在滚动播出沿海各地发布的避难通知，例如，青森县已经有一万九千多户被要求离家进入公用避难设 施。日本全国到现在为止已有40万人离开家园。整个流程顺畅，井然有序。这一切，一方面反映了日本在自然灾害面前出色的准备工作，另一方面也反映了日本民 间的恐惧。

广播员在不断在播报各地海平面的增高情况，镜头不时切换到沿岸各地，报道当地状况和抢险准备的情况，很多沿海公路如东名高速公路已经关闭，海滨公园停止营业，船舶纷纷进入避难路线。经常有画外音插断播音员的播报，紧急通报某地海平面出现异常增高。转眼间就有了一种陷入某场战争的感觉。

发个图，看的比较清楚。整个日本靠太平洋的一边，全部是海啸警报。

公司做的项目，正好是给各个电视台做的天气预报项目，地震台风海啸的预报，也包含在内。关键时刻，日本电视台打电话说，预报图显示的有误，只能看到大阪的浪高，其他地方没有浪高。导致只能显示部分的警报图。东京电视台也打电话说电视上滚动显示的警报文字，用我们的程序处理不了，显示出不来。马上乱套了，当天公司几个人都通宵在处理。最后强制显示全国的警报图。

最后发现，日本电视台预报图显示有误，其实是正确的，本来其他地方就没有浪高。为什么呢？因为根本就没那么大的浪！

日本气象厅在3月1日10点15分全面解除太平洋沿岸海啸警报。
气象厅负责地震海啸检测的课长在记者会见中谢罪称，“对于海啸预测大大超过了实际情况，以及警报时间过长表示歉意。”

为什么这次的地震，没有引起很大的海啸呢？

智利此次地震所引发的海啸也具有很强的方向性，英国威尔士大学新港学院（University of Wales, Newport）的Simon Haslett 说“这回的海啸非常有方向性，而不是那种均匀向四周传播的‘往池塘里扔石头’似的波浪”。他表示离震中最近的海岸，以及胡安费尔南德斯群岛（Juan Fernandez Islands）海啸非常强，但是其他方向的海啸能量和高度迅速减退。

而且，地震震源的相对深度—35公里—可能也减小了海床的上升，而正是海床的上升排挤了海水。英国伦敦大学学院Bill McGuire表示“相比比2004年的印度洋地震，智利地震要更深，释放到地表的能量也更少”。

虚惊一场啊。

至于东京电视台的预报文字处理不出来，经过我一步步Debug，最后发现，是MFC的一个Bug造成的！气死我了。导致所有代码涉及这个Bug的地方都要修改。下篇日志，详细说说这个Bug。