Differentiating between original and typedef'd types

Started by
16 comments, last by SiCrane 17 years, 8 months ago
Quote:Original post by Bregma
For a start, Microsoft's BOOL type has at least 3 distinct meaningful values. It's not a boolean type, it's an integral type.


FileNotFound?
Advertisement
Ex: check the return values for GetMessage(). The return value type is a BOOL, but can be 0, -1 or some other value, with -1 and other values having different meanings.
The Win API uses BOOL < 0 for errors. The trick is, they still evaluate to false, but carry more specific information than just 'operation failed'.
Quote:Original post by Deyja
The trick is, they still evaluate to false, but carry more specific information than just 'operation failed'.

You have a very odd definition of "evaluate to false".
Well, okay, they evaluate to exactly the opposite of what I said. The point is, all the 'error values' evaluate to the same boolean value.
It's not quite that straightforward. For example, CreateProcess() returns 0 on error, and you use GetLastError() to figure out the error type, while GetMessage() returns -1 on error, but 0 is a non-error return value. So the CreateProcess() error evaluates to boolean false, but GetMessage() error evaluates to boolean true.
... And after all that, they have the nerve to call it 'BOOL'. I think that's the *real* WTF. :)
Eh. It's one of the consequences of maintaining a more or less single API over many, many moons. Originally BOOL meant a boolean value, but sometimes it was used in places where it wouldn't be adequate. It happens. This is why more recent WinAPI functions use DWORD as a return type even when the return value would be interpreted as a boolean value.

edit: spelling

[Edited by - SiCrane on August 12, 2006 6:22:49 PM]

This topic is closed to new replies.

Advertisement