The most stupid Bug in C Language History

Introduction: This article is from The "The most stupid C bug ever". The translation is compiled by Chen Hao of cool shell network to compile "The most stupid Bug in The history of C language". The content is as follows:
 
This article is very interesting and I will share it with you. I believe that you will make such a bug even if you are a master. Let's take a look at the author's Bug ..
 
First, I want to use a program to create a file. If there is a file name, I will create a real file. If not, I will call tmpfile ()? Create a temporary file. This program is the C program downloaded from HTTP. Code = 200 is the HTTP return code.
 
Else if (code = 200) {// Downloading whole file
/* Write new file (plus allow reading once we finish )*/
G = fname? Fopen (fname, "w +"): tmpfile ();
}
But this program can only work in Unix/Linux, because of Microsoft? Implementation of tmpfile? C: \ is used as the directory for storing temporary files. This is a big problem for those who do not have administrator permissions. In Windows 7, even if you have the administrator privilege, the problem may occur. Therefore, the above program needs to be processed in different ways on the Windows platform, and the Windows tmpfile () function cannot be used directly.
 
So the author first writes down this question and writes FIXME in the comment:
 
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 ();
}
Then, the author thinks it is necessary to write a cross-platform Compilation:
 
FILE * tmpfile (void ){
# Ifndef _ WIN32
Return tmpfile ();
# Else
// Code for Windows;
# Endif
}
Then, the author thinks this implementation is very bad and will find a name conflict, because this function is too ugly. So he reconstructed his code -- write a self-implemented tmpfile ()-w32_tmpfile, and then rename the function as tmpfile () with a macro definition in Windows (). (Chen Hao Note: This is a standard cross-platform code writing method)
 
# Ifdef _ WIN32
# Define tmpfile w32_tmpfile
# Endif

FILE * w32_tmpfile (void ){
// Code for Windows;
}
Done! Compile and run the program. Depend! Why didn't I call my w32_tmpfile? Debugging and one-step tracking are not called! Is there a problem with the question mark expression? Change it to the if-else statement. All right!
 
If (NULL! = Fname ){
G = fopen (fname, "w + ");
} Else {
G = tmpfile ();
}
The question mark expression should not be a problem. Isn't our macro playing a direct role on the question mark expression? Is this a bug of compiler pre-compilation? I suspect.
 
Now let's take a look at all the codes and compare them:
 
Code that works properly
 
Code that can work
 
# 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 ();
}
}
Code that cannot work normally
 
Code that cannot work
 
# 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 ();
}
Maybe you saw this bug in the beginning, but the author didn't. All the problems are described in the Notes:
 
/* 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 :\
Have you seen the last C? In C, "\" indicates that this line is not over. Therefore, the subsequent code is also annotated. This is the real cause of this bug!
 
The reason why I changed it to if-else is that the author commented on the code of the old question mark expression. Therefore, the code that can work is:
 
/* 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 ();
}
I believe that when the author finds the cause of this problem, he will say "fuck "! I also believe that this bug takes a lot of time!
 
Finally, I share a previous mistake.
 
I have a small function that requires an int * pInt type, and then I need to divide this int * pInt in my code. So my code looks like this:
 
Float result = num/* pInt;
....
 
/* Some comments */
 
Num ++;
Because I used vi to write code at the time, there was no syntax highlighting, and all my programs were compiled, but it was strange. I don't know. When I use gdb, I find some statements pass through. This problem took me a lot of time. I finally found that the problem was caused by no space. TNND. I will use the code highlighted plug-in to display the above Code,
 
Float result = num/* pInt;
....

/* Some comments */

Num ++;
My code becomes:
 
Float result = num-x <10? F (result): f (-result );
My mistake is a combination of dummies and the above author's mistake.

 

This article is from "Jungle tigers"