The dumbest bug in the history of C language

The dumbest bug in the history of C languageAugust 26, 2011 Chenhao Comments Read comments 38,650 people read

This article comes from "The most stupid C bug ever" and is very interesting to share with you. I believe that such a bug, even if you are a master you will make. Take a look at the author's bug.

First, the author wants to use a program to create a file, if there is a filename, to create a real file, if not, call the "Tmpfile" ()? create temporary files. His program is the HTTP download of the C program. CODE==200 is the return code for HTTP.

1 2 3 4

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

But this program can only work under Unix/linux, because the implementation of Microsoft's Tmpfile () has chosen C:\ As a storage directory for temporary files, this is a big problem for people who do not have administrator privileges, even if you have administrator privileges under Windows 7. Therefore, the above program in the Windows platform needs to be handled in a different way, you can not directly use the Windows Tmpfile () function.

So the author wrote down the question first, writing down the fixme in the note:

1 2 3 4 5 6 7

else if (code = =) {//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 (); }

The author then felt the need to write a cross-platform compilation:

1 2 3 4 5 6 7

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

Then, the author felt that it was a bad idea to find the name conflict because the function was so ugly. So he refactored his code--write a tmpfile () –w32_tmpfile of his own implementation, and then rename the function Tmpfile () with a macro definition under Windows. (Chenhao Note: This usage is the standard cross-platform code)

1 2 3 4 5 6 7

#ifdef _WIN32 #define TMPFILE w32_tmpfile #endif FILE * w32_tmpfile (void) {//code for Windows;}

Get. Compile the program and run it. By. Incredibly no call to my w32_tmpfile (), what a problem. debugging, one step tracking, and sure enough no call to. Is there a problem with the question-mark expression? Change into If–else statement, OK.

1 2 3 4 5

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

The question mark expression should not have a problem, does our macro have no effect on the question mark expression, this is a compiler's precompiled bug. The author suspects that.

Now we're going to look at all the code together and compare:

code that Works

Code to work with

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

#ifdef _WIN32 # define Tmpfile w32_tmpfile #endif FILE * w32_tmpfile (void) {code for Windows;} else if (code = =) {//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 (); } }

code that doesn't work correctly

Code that can't work

1 2 3 4 5 6 7 8 9 10 11 12 13-14

#ifdef _WIN32 # define Tmpfile w32_tmpfile #endif FILE * w32_tmpfile (void) {code for Windows;} else if (code = =) {//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 (); }

You may have seen the bug from the beginning, but the author didn't. All the questions are on the note:

1 2 3

/* 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:\

Did you see the last c:\? In C, "\" means that the line does not end, and the following code is also commented. That's the real reason for this bug .

The reason to change to If-else is because the author commented on the old question-mark expression, so the code that worked was:

1 2 3 4 5 6 7

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

I believe that when the author finds out the cause of the problem, he will scold a "damn". I also believe that this bug cost the author a lot of time.

In the end, I also share a mistake I made before.

I have a small function that needs to pass in a int* pint type, and then I need to divide this int* pint in my code. So my code came down to this:

float result = Num/*pint;
....

/* Some comments * *

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

Because I used VI to write code, so there is no syntax highlighting, and my program has been compiled, but there are very strange things. I do not know, using the GDB mode, found that some statements directly passed. This problem let me spend a lot of time, finally found that the problem was no space caused, tnnd, I use the code highlighted in the plugin to display the above code,

1 2 3 4 5 6

float result = num/*pint; ..../* Some comments * * *-x<10? F (Result): f (-result);

Holly shit! My Code has become:

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

Damn it. My mistake in the stupidity of the above and the author of the mistake has a fight.

(End of full text)