C语言中史上最愚蠢的Bug

C语言中史上最愚蠢的Bug

本文来自“The most stupid C bug ever”,很有意思,分享给大家。我相信这样的bug,就算你是高手你也会犯的。你来看看作者犯的这个Bug吧。。

首先,作者想用一段程序来创建一个文件,如果有文件名的话,就创建真正的文件,如果没有的话,就调用?tmpfile()?创建临时文件。他这段程序就是HTTP下载的C程序。code==200就是HTTP的返回码。

else if (code == 200) {     // Downloading whole file
    /* Write new file (plus allow reading once we finish) */
    g = fname ? fopen(fname, "w+") : tmpfile();
}

但是这个程序,只能在Unix/Linux下工作,因为 Microsoft 的?tmpfile()的实现?居然选择了 C:\ 作为临时文件的存放目录,这对于那些没有管理员权限的人来说就出大问题了,在Windows 7下,就算你有管理员权限也会有问题。所以,上面的程序在Windows平台下需要用不同的方式来处理,不能直接使用Windows的tmpfile()函数。

于是作者就先把这个问题记下来,在注释中写下了FIXME:

else if (code == 200) {     // Downloading whole file
    /* Write new file (plus allow reading once we finish) */

    // FIXME Win32 native version fails here because
    //   Microsoft's version of tmpfile() creates the file in C:\
    g = fname ? fopen(fname, "w+") : tmpfile();
}

然后,作者觉得需要写一个跨平台的编译:

FILE * tmpfile ( void ) {
#ifndef _WIN32
    return tmpfile();
#else
    //code for Windows;
#endif
}

然后,作者觉得这样实现很不好,会发现名字冲突,因为这样一来这个函数太难看了。于是他重构了一下他的代码——写一个自己实现的tmpfile() – w32_tmpfile,然后,在Windows 下用宏定义来重命名这个函数为tmpfile()。(陈皓注:这种用法是比较标准的跨平台代码的写法)

#ifdef _WIN32
  #define tmpfile w32_tmpfile
#endif

FILE * w32_tmpfile ( void ) {
    //code for Windows;
}

搞定!编译程序,运行。靠!居然没有调用到我的w32_tmpfile(),什么问题?调试,单步跟踪,果然没有调用到!难道是问号表达式有问题?改成if – else 语句,好了!

if(NULL != fname) {
    g = fopen(fname, "w+");
} else {
    g = tmpfile();
}

问号表达式不应该有问题吧,难道我们的宏对问号表达式不起作用,这难道是编译器的预编译的一个bug?作者怀疑到。

现在我们把所有的代码连在一起看,并比较一下:

能正常工作的代码

#ifdef _WIN32
#  define tmpfile w32_tmpfile
#endif

FILE * w32_tmpfile ( void ) {
    code for Windows;
}

else if (code == 200) {     // Downloading whole file
    /* Write new file (plus allow reading once we finish) */
    // FIXME Win32 native version fails here because
    //     Microsoft's version of tmpfile() creates the file in C:\
    //g = fname ? fopen(fname, "w+") : tmpfile();
    if(NULL != fname) {
        g = fopen(fname, "w+");
    } else {
        g = tmpfile();
    }
}

不能正常工作的代码

#ifdef _WIN32
#  define tmpfile w32_tmpfile
#endif

FILE * w32_tmpfile ( void ) {
    code for Windows;
}

else if (code == 200) {     // Downloading whole file
    /* Write new file (plus allow reading once we finish) */
    // FIXME Win32 native version fails here because
    //    Microsoft's version of tmpfile() creates the file in C:\
    g = fname ? fopen(fname, "w+") : tmpfile();
}

也许你在一开始就看到了这个bug,但是作者没有。所有的问题都出在注释上:

/* Write new file (plus allow reading once we finish) */
// FIXME Win32 native version fails here because
//     Microsoft's version of tmpfile() creates the file in C:\

你看到了最后那个C:\吗?在C中,“\” 代表此行没有结束,于是,后面的代码也成了注释。这就是这个bug的真正原因

而之所以改成if-else能工作的原因是因为作者注释了老的问号表达式的代码,所以,那段能工作的代码成了:

/* Write new file (plus allow reading once we finish) */
// FIXME Win32 native version fails here because Microsoft's version of tmpfile() creates the file in C:    //g = fname ? fopen(fname, "w+") : tmpfile();
if(NULL != fname) {
    g = fopen(fname, "w+");
} else {
    g = tmpfile();
}

我相信,当作者找到这个问题的原因后,一定会骂一句“妈的”!我也相信,这个bug花费了作者很多时间!

最后,我也share一个我以前犯的一个错。

我有一个小函数,需要传入一个int* pInt的类型,然后我需要在我的代码里 把这个int* pInt作除数。于是我的代码成了下面的这个样子:

float result = num/*pInt;
….

/*  some comments */

-x<10 ? f(result):f(-result);

因为我在我当时用vi编写代码,所以没有语法高亮,而我的程序都编译通过了,但是却出现了很奇怪的事。我也不知道,用gdb调式的时候,发现有些语句直接就过了。这个问题让我花了很多时间,最后发现问题原来是没有空格导致的,TNND,下面我用代码高亮的插件来显示上面的代码,

float result = num/*pInt;
....

/*  some comments */

-x<10 ? f(result):f(-result); 

Holly Shit!  我的代码成了:

float result = num-x<10 ? f(result):f(-result);

妈的!我的这个错误在愚蠢程度上和上面那个作者出的错误有一拼。

(全文完)

(转载本站文章请注明作者和出处 酷 壳 – CoolShell ,请勿用于任何商业用途)

好烂啊有点差凑合看看还不错很精彩 (43 人打了分,平均分: 4.40 )
Loading...

C语言中史上最愚蠢的Bug》的相关评论

    1. 是的,五笔。谢谢指正。我打五笔现在完全记不住字根了,都不过脑,完全是凭感觉下意识打字。所以,很容易出错。

  1. 的确,这样的”bug”太恶心了,我以前也遇到过,后来用语法高亮可以基本杜绝这类bug,不过我觉得良好的代码风格也会有助于减少这类bug。
    第一个例子中,我比较反对这样的注释方法,可能我有些极端,即使是单行,我也会用/* … */注释
    第二个例子中,我习惯于这样写 float result = num / *pInt;

  2. 很早之前就发现了,在C语言中如果除数来自于一个指针的解引用,那么一个不小心就变成了注释头……
    所以自己实现一个小语言的时候把解引用符号定义为 ‘@’

  3. 看来在运算符两边留个空格真的是非常重要啊。博主的那个错误就不会出现了。。。。

  4. 同感,运算符留空格,然后 *p 写成(*p),这样更能直接地表达出写程序的人的想法,也不容易错。
    多点括号总没有关系吧

    1. 这是我的失误,原来的代码比较复杂,本想给一个简单点的示例,结果还给错了,sorry,我修改了。

  5. 这个错误在Vim下是不可能犯的,因为Vim会语法高亮成注释。
    《C++ Exceptional》中介绍过一个更隐蔽的问题:

    在一个符合标准的C++编译器上,下面程序的输出是什么?

    #include <iostream>
    int main() {
        int x = 1;
        for (int i = 0; i < 100; ++i);
            // 下面这行代码会干些什么? 递增???????????/
            ++x;
        std::cout << x << std::endl;
    }

    // 如果你认为答案是2,那你就太2了
    //////////
    /////////
    ////////
    ///////
    //////
    /////
    ////
    ///
    //
    /

    正确答案是输出:1

  6. 在VC下输出是1
    从编译时报的错就可以看出来的吧
    warning C4010: single-line comment contains line-continuation character

  7. ytj :
    这个错误在Vim下是不可能犯的,因为Vim会语法高亮成注释。
    《C++ Exceptional》中介绍过一个更隐蔽的问题:
    在一个符合标准的C++编译器上,下面程序的输出是什么?
    #include
    #include
    int main() {
    int x = 1;
    for (int i = 0; i < 100; ++i);
    // 下面这行代码会干些什么? 递增???????????/
    ++x;
    std::cout << x << std::endl;
    }
    // 如果你认为答案是2,那你就太2了
    //////////
    /////////
    ////////
    ///////
    //////
    /////
    ////
    ///
    //
    /
    正确答案是输出:1

    不是5050吗??

  8. cndj :
    @vanxining
    汗…for后面有个分号, 而且那个注释是?????/ 也就是下一行也被注释掉了, 所以是1

    哦,第一个明白了……我觉得好一点的编译器都会提示这种奇怪的写法,不算什么
    第二个,C++还有这种特性吗?我只知道“\”会将这一行扩展到下一行……

  9. vanxining :

    cndj :
    @vanxining
    汗…for后面有个分号, 而且那个注释是?????/ 也就是下一行也被注释掉了, 所以是1

    哦,第一个明白了……我觉得好一点的编译器都会提示这种奇怪的写法,不算什么
    第二个,C++还有这种特性吗?我只知道“\”会将这一行扩展到下一行……

    用 g++ 会提示没有 enable trigraph, enable trigraph 后 ??/ 相当于 \

  10. @zhanwu
    可能各编辑器处理方式不一样吧,至少我拿vim试第二行也是会显示为注释的。

    语法高亮很重要啊,很多这类小细节,比如有些语言里面定义字符串时是否会进行转义,都能通过语法高亮看出来。

  11. 换行连接符“\”的优先级高于单行注释符“//”吗?
    另外,这些语法陷阱究竟是C的还是C++的?现在对这两种语言的语法已经有点晕了。

  12. 博主好文! 我也试了试, 确实会有如文问题.
    勘误一处, 作者将 tmpfile 重构为 w32_tmpfile 是因为他认为不能够优化.
    原文:
    That has a performance impact on all platforms: the direct call to tmpfile() is now an indirect, which defeats optimization, and well, everything.

  13. 我想,类似的错误,程序员很难完全避免。更严格的语法,更苛刻的语法检查器,可以避免用1个小时去发现一个空格的笔误。

  14. LZ的错误神了……我怎么都想不到/*这个问题能够用什么正常的方式体现出来……

  15. 看来良好的编程风格的确是非常重要的 要是因为这些小细节 浪费大量时间 就太不值得了

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注