How to return bool value in masm?
xor eax, eax
retn xx
xor eax, eax
inc eax
retn xx
xx depends on the calling convention and the number of parameters.
Replace eax with rax in 64-bit.
retn xx
xor eax, eax
inc eax
retn xx
xx depends on the calling convention and the number of parameters.
Replace eax with rax in 64-bit.
Assembly is different than the other higher level languages. In assembly you control all the registers (Technically, you could not save any register and return several values without pointing to a structure even.), in C or VB (ect..) this is automated for you through the eax register. In order to make things simple in the higher level languages, they consider everything to be a dword even boolean values.
ti_mo_n was correct, even though you are really returning 00000001 for TRUE and 00000000 for FALSE, it is still a 1 or 0 value. By clearing the rest of the bits, you are free to cmp or test or and EAX instead of just AL for your boolean value.
ti_mo_n was correct, even though you are really returning 00000001 for TRUE and 00000000 for FALSE, it is still a 1 or 0 value. By clearing the rest of the bits, you are free to cmp or test or and EAX instead of just AL for your boolean value.
Simply said, 0 is FALSE and any other value, in any part of any register can be treated as TRUE. Doesn't matter if it is AL, AH or high 16-bits of EAX or wherever else. And Timo's code is fine. 1 DOES define TRUE no matter where in the register that bit is set.
Well thanks to all :)
There are only two kinds of programmers... those who can count to 10, and those who can't.
TRUE is simply anything that is not FALSE, however there are cases where it is more specific such as when dealing with returns for VARIANTs using IDispatch, in that case the value must be 0xFFFF, returning any other value will fail. Because of bad programming practices (of which I am equally guilty) a lot of programs test for TRUE (+1) and will fail without it when they should always test for FALSE instead. The reason to test for FALSE is that a test for TRUE extends the definition of FALSE to anything that is not 1, while a test for FALSE does not.
Yeah, a painfully easy mistake to make, and one that will have you scratching your head and step-debugging seemingly sane code.
With some languages it doesn't matter.
Eg, in C/C++ you can write if (x), which is equivalent to if (x == true), because by definition, true is anything that is not 0 (false). So in that language, it is solved in the == operator. I'm not sure what MASM does with the == in its .IF macro. If it follows C/C++ behaviour, you'd be safe... However if you manually use instructions like cmp etc, you'll have to be careful not to fall into the trap.
You'd still have to be careful when manipulating VARIANTs though, because those may be passed onto external code, which expects explicit values of VARIANT_TRUE or VARIANT_FALSE.
You can't just use 0 for false and any nonzero value for true.
Eg, in C/C++ you can write if (x), which is equivalent to if (x == true), because by definition, true is anything that is not 0 (false). So in that language, it is solved in the == operator. I'm not sure what MASM does with the == in its .IF macro. If it follows C/C++ behaviour, you'd be safe... However if you manually use instructions like cmp etc, you'll have to be careful not to fall into the trap.
You'd still have to be careful when manipulating VARIANTs though, because those may be passed onto external code, which expects explicit values of VARIANT_TRUE or VARIANT_FALSE.
You can't just use 0 for false and any nonzero value for true.
ti_mo_n,
The above will guarantee a "true" return. Any value other than zero should be considered TRUE. ESP is never zero.
Ratch
MOV EAX,ESP
RETThe above will guarantee a "true" return. Any value other than zero should be considered TRUE. ESP is never zero.
Ratch
Ratch, that's extremely cute and obscure code. ;) If you didn't explain I would have spent some time trying to figure it out.
hehe, it's nice indeed.