The most stupid in the history of the C language Bug

This article from the " at The MOST Stupid bug Ever C ", very interesting, for everyone to share. I believe that such a bug, even if you are a master you will make. You look at this Bug author committed it. .

First, the author would like to use a program to create a file, if the file name, then it really created a file, if not, it calls? Tmpfile () ? Create temporary files. He HTTP download this program is a C program. code == 200 is HTTP return code.

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

But the program can only work in Unix / Linux, because Microsoft's? Tmpfile () implementation actually chose C:? \ As a temporary file storage directory, which lies great for those who do not have administrator privileges for problem, in Windows 7, even if you have administrator access is also a problem. Therefore, the above procedure under Windows platform needs to be treated in different ways, can not directly use the Windows tmpfile () function.

So the authors put that question down and wrote FIXME in a comment:

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

Then, the author felt the need to write a cross-platform compiler:

1 FILE * tmpfile ( void ) {
2 #ifndef _WIN32
3     return tmpfile();
4 #else
5     //code for Windows;
6 #endif
7 }

Then, the authors feel that this realization is very bad, you will find the name of the conflict, because then this function too difficult to read. So he reconstructs what his code - write a tmpfile () own implementation - w32_tmpfile, then, in the Windows definition to rename this function with the macro tmpfile (). (Chen Hao Note: This usage is relatively standard cross-platform code wording)

1 #ifdef _WIN32
2   #define tmpfile w32_tmpfile
3 #endif
4   
5 FILE * w32_tmpfile ( void ) {
6     //code for Windows;
7 }

Get! Compiler, run. by! There's no call to my w32_tmpfile (), what is the problem? Debug, single stepping, and she did not call to! Is it a question mark expression in question? Change if - else statement, well!

1 if(NULL != fname) {
2     g = fopen(fname, "w+");
3 } else {
4     g = tmpfile();
5 }

Question mark expression should not be a problem with it, do not direct our macro expression to the role of a question mark, that really is a bug precompiled compiler? Author suspect.

Now we look at all the code together, and compare:

The code works fine

01 #ifdef _WIN32
02 #  define tmpfile w32_tmpfile
03 #endif
04   
05 FILE * w32_tmpfile ( void ) {
06     code for Windows;
07 }
08   
09 else if (code == 200) {     // Downloading whole file
10     /* Write new file (plus allow reading once we finish) */
11     // FIXME Win32 native version fails here because
12     //     Microsoft's version of tmpfile() creates the file in C:\
13     //g = fname ? fopen(fname, "w+") : tmpfile();
14     if(NULL != fname) {
15         g = fopen(fname, "w+");
16     } else {
17         g = tmpfile();
18     }
19 }

The code does not work

01 #ifdef _WIN32
02 #  define tmpfile w32_tmpfile
03 #endif
04   
05 FILE * w32_tmpfile ( void ) {
06     code for Windows;
07 }
08   
09 else if (code == 200) {     // Downloading whole file
10     /* Write new file (plus allow reading once we finish) */
11     // FIXME Win32 native version fails here because
12     //    Microsoft's version of tmpfile() creates the file in C:\
13     g = fname ? fopen(fname, "w+") : tmpfile();
14 }

Perhaps you are beginning to see this bug, but the authors did not. All the problems out in the comments:

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

You saw that last C: \ it? In C, "\" on behalf of this trip is not over, so the code behind has become a comment. This is the real reason for this bug !

The reason why change if-else able to work because of old code annotated expression of a question mark, so that part of the code can work became:

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

I believe that when the cause of this problem is found, will criticize a "Damn!" I also believe that this bug spend a lot of time!

Finally, I have a share of a mistake I've made.

I have a small function, need to pass in a type int * pInt, and then I need in my code this int * pInt as the divisor. So I became the following code like this:

1 float result = num/*pInt;
2 ….
3  
4 /*  some comments */
5  
6 num++;

Because I had written in my vi code, so there is no syntax highlighting, and my programs are compiled through, but there was a very strange thing. I do not know, use gdb modal and found some statements directly before. The problem I spend a lot of time, finally found the problem turned out to be no spaces caused, TNND, I use the following code highlighting plug-in to display the code above,

1 float result = num/*pInt;
2 ....
3   
4 /*  some comments */
5   
6 num++;

! Holly Shit my code became:

1 float result = num/num++;

Oh shit! I have this stupid mistake on the above programs and error out of a fight.

(Applause.)

Original Transfer: http://coolshell.cn/articles/5388.html


Reproduced in: https: //my.oschina.net/dake/blog/196642

Guess you like

Origin blog.csdn.net/weixin_33941350/article/details/91507877