BOOL or BOOLEAN - that is the question?

I somehow never thought about the fact that it is better to use BOOL or BOOLEAN? Of course, BOOL is both shorter and in all textbooks on Windows it is BOOL. No matter how wrong! Just yesterday, I spent an hour looking for a mistake where it shouldn’t be.

It turned out that the only true type directly associated with the bool type, which is defined by C ++ standards, is BOOLEAN. And BOOL is nothing more than “typedef int BOOL;” and is in windows.h (more precisely in WinDef.h, but it doesn't matter)

Let's take a closer look at the source code of the function, comparing two numbers:

#include <stdio.h> #include <windows.h> bool CompareInt(int i1, int i2) { if (i1==i2) return true; //UPD1:  TRUE else return false; //UPD1:  FALSE } typedef BOOL (*CallBack)(int, int); void main(void) { CallBack IsEqual = (CallBack)CompareInt; if ( !IsEqual(0x1234, 0x5678) ) printf("Not equals"); else printf("Equals"); } 

After compiling Visual Studio and running, we have: Equals
')
Then change BOOL to BOOLEAN:

 typedef BOOLEAN (*CallBack)(int, int); 

Compile, run, we get: Not equals (which should have been right from the start)

Conclusion: never use BOOL, only BOOLEAN.

UPD1: Corrected in the return function, it was TRUE / FALSE became true / false for the purity of the experiment.

UPD2: Revealing "black magic." The bool returns in char type (CPU al register), since bool in Visual Studio is equal to char (and BOOLEAN is also equal to char there, so replacing BOOL with BOOLEAN removes the error).

But the BOOL type is equal to int (the eax register), so when the function returns false (also known as FALSE), only the low byte al is set to zero, and the high bytes (ah and other eax) will be non-zero garbage, to which BOOL, the bool result that has absorbed itself, will react as if eax! = 0 and an error will occur.

We would have to switch to the branch with eax == 0 (Not equals) inside the last if, and switch to the branch with eax! = 0 (Equals), because the CompareInt function returned us only al to 0, and the upper (garbage) bytes in eax, inside the CompareInt function it was (erroneously?) not set to 0.

UPD3: By the way, this code was compiled by the ancient (2006) Borland Builder C ++, all eax bits when returning false inside the CompareInt function are explicitly set to 0 by xor eax, eax - therefore there is no error.