C++ 'true' and 'false' keywords suddenly not true or false in Visual C++ 6.0

Question

My compiler (VC++ 6.0 sp6) has apparently gone insane. In certain pieces of code I'm seeing that 'bool mybool = true;' evalutes to and assigns false, and vice versa for true. Changing the true/false keywords to 1/0 makes it work fine. The same code compiles elsewhere fine without changing the true/false keywords.

What could possibly cause this? My first thought was RAM or disk corruption, but that all checked out fine. I'm not far from reformatting my drive and reinstalling everything, but I'm terrified I'd still see the same misbehavior.

Is it even technically possible for a macro or linked-in library somewhere to screw up the meaning of 'true' and 'false'?

UPDATE: Mystery solved. An environment variable flag on my machine was set to 'false' and the way this was interpolated by some preprocessor code redefined the keyword.

Answer 1

A preprocessor macro could certainly do it, although that would be pretty surprising. One way to check if that is the case would be

#ifdef true
#  error "true is defined as a macro"
#endif
#ifdef false
#  error "false is defined as a macro"
#endif

Response to comments:

Find a non-header file where you see this behavior, preferably one with few #includes.

In the middle of the list of includes, put the #ifdef #error directives.

if the error trips you know it's in the first half of includes, if it doesn't it's in the second half. Split the half in half and repeat. When you narrow it down to one header, open that header. If that header includes any headers repeat the process for the list of headers it includes. Eventually you should be able to find the #defines . Tedious, I agree.

Answer 2

Most likely a header file is flipping the values via macro - although why I could not hazard a guess. Any chance that file is being compiled as C and others as C++ and there's some #ifdef/#define code somewhere that is attempting to 'fix' the true/false values, but got them wrong?

Answer 3

Check for #define true 0 and #define false 1

Answer 4

It's technically possible to redefine bool but I can't see why your particular environment would be the only one where this issue surfaces.

Perhaps someone is having some fun with you?

Answer 5

Buffer overflows and writing into uninitialized memory can also account for such behavior. For example, if you have an array and bool allocated in adjacent memory locations and accidentally write beyond the bounds of the array.

Answer 6

Even in Visual Studio 2003 also sometimes it happens to me. But I don't know the exact cause for this. This happens while checking the return value of a function. Even though I am returning true from a function, while assigning the return value in calling function, true is getting converted to false and false to true.

In that case, I do check for some other output parameter.

Answer 7

If you're seeing this problem when checking variable values in the debugger, and you're running a release build, it could just be an artifact of the debugging system. The easiest way to check this would be to add some code along the lines of:

if (mybool)
    printf("mybool is true\n");
else
    printf("mybool is false\n");

You'll be able to quickly identify whether the debugger is accurate or not.

Answer 8

First, VC6 is ancient and buggy. There are cases where it just generates incorrect code, which could be the answer to your problem. Don't use VC6 if you have a choice.

Second, what you're seeing is most likely just the result of optimizations. Does your code behave correctly? If so, it's just that the debugger gets confused because the code that is executed is different (due to optimizations) than the source code.

Answer 9

I vaguely recall that with VC6 you could run the pre-processor all by itself and see its output. It may be a compiler switch.

In any event, this is almost certainly the result of #defines gone awry. If it was a memory overwrite, as has been suggested, you would likely be seeing other equally bizarre behaviors.

Answer 10

Problems like this are scary, because you really have no place to start.

The first test that I'd do is to search all of the source code for your project for things that matches both "#define" and "true", or "#define" and "false." If you have someone around who knows Perl, that should be a fast script.

Do you depend on linking against some external libraries that may have changed? If you suspect some weirdness with something that you're linking against, you could try is the following steps:

• Make a program that checks the value of true/false.
• Compile this program, making sure to link this program against all of the libraries that your source code.
• Run your program, and see if your minimal program exhibits the true/false bug that is affecting your problem.

If that minimal program has the bug, you've isolated the problem down to something that you're doing with linking. The next obvious test after that is to link the program against nothing but the standard C++ libraries to test if your compiler is somehow at fault.

Finally, before reformatting your machine have someone else compile your code. That's really easy, and if the Perl script turned up nothing I'd definitely ask a co-worker for some help.