views:

122

answers:

3

I came across some code written in C that looks like this:

if (file == NULL)
     TRUE; /* <-- What does that mean? */

I think that it is another way of saying:

if (file == NULL);

But am I missing something, and is there a reason to do it the first way as opposed to the second way?

UPDATE:

Doing some digging, TRUE is defined as such:

#define TRUE !0
+2  A: 

This looks like a statement with no effect, but what is TRUE defined to be (It isn't standard)? If it is just 1 as expected, this has no effect. There is no reason to do either of these.

arsenm
+3  A: 

I think the reason to write like this is to get rid of annoying compiler warnings.

It is true for MSVC that the second statement will cause compiler to warn about empty controlled statement or something like. However TRUE; is a regular valid non-empty statement.

Keynslug
I can think of better ways of improving the line `if (file == NULL);`, assuming `file` is the name of a variable. If it's followed by an `else`, perhaps the original author was unaware of `!=` ;-)
Steve Jessop
But if he put it there as a kind of `TODO:`, then it would be wisier to let the compiler generate the warning.
ruslik
+7  A: 

Just a guess - I suspect at some point in history someone wanted to set a breakpoint on that TRUE line.

I've worked with debuggers where doing that might have been easier than trying to set a conditional breakpoint. But it's been a long, long time since that might have been true. I still find myself doing something similar in some environments if the condition I want to break on involves a function call or if a conditional breakpoint slows things down too much (that happens a lot on embedded targets where evaluation the condition in the debugger involves a lot of communication over the JTAG link).

However, that do-nothing code shouldn't have made it into version control.

Michael Burr
I suspect that that Is probably the intent of the code, after looking at the code in depth and with all the help from everyone, thank you!
Richard J. Ross III
But assuming that `#define TRUE !0` will there any code be produced by the compiler for the statement `TRUE;` even on debug build?
Keynslug
`!0` can be evaluated at compile time, and any sane compiler (even for 8-bit micros back in the day) would do at least that much. Some of those, however, would happily compile `1;` as `MOV AL,#1` or the equivalent. Even with the "optimizer" enabled, as I recall for a 6809 compiler I used many years ago. A good compiler would vanish the whole condition after noticing the constant non-volatile expression as a statement.
RBerteig
Keynslug: you're right (at least for Visual Studio). The 'do nothing' statement often has to be something a bit more complex (like maybe `file = (FILE* volatile) file;`).
Michael Burr