The Most Stupid Embedded C Bug Ever: A Missing Space That Turned Code Into a Comment

The author starts with a C program that downloads a file via HTTP (checking code == 200) and writes the data either to a named file ( fopen(fname, "w+")) or to a temporary file created by tmpfile(). This works on Unix/Linux, but on Windows the standard tmpfile() creates the file in C:\, which can cause permission problems for non‑admin users.

To handle the Windows case, the author adds a conditional compilation block that defines a custom w32_tmpfile() function and uses a macro to rename tmpfile to w32_tmpfile on Win32 platforms:

#ifdef _WIN32
#define tmpfile w32_tmpfile
#endif

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

After compiling and running, the program still does not call w32_tmpfile(). The author suspects the ternary operator might be the culprit and rewrites the logic using an explicit if‑else statement, which appears to work.

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

Further investigation shows that the macro substitution does not affect the ternary expression, leading the author to wonder whether a compiler bug is involved.

Comparing two versions of the code—one that works and one that does not—the author discovers that the non‑working version contains the line:

g = fname ? fopen(fname, "w+") : tmpfile();

while the working version uses the explicit if‑else shown earlier. The real cause, however, is hidden in the comments: a backslash at the end of a comment line ("Microsoft's version of tmpfile() creates the file in C:\") escapes the newline, causing the following code to be treated as part of the comment. This makes the ternary expression effectively commented out, so the program never reaches the intended branch.

Replacing the ternary expression with if‑else works because the original line is now commented out, and the active code executes correctly.

The article then shares a similar personal mistake: a missing space after a comment delimiter caused the line float result = num/*pInt; to be parsed as a comment, and the subsequent expression -x<10 ? f(result):f(-result); was compiled incorrectly as float result = num-x<10 ? f(result):f(-result);. Adding the missing space fixes the bug.

Both cases illustrate how tiny syntactic oversights—an escaped newline in a comment or a missing space—can produce hard‑to‑detect bugs, especially in low‑level C code that must run across different platforms.