16 Nov
2014
16 Nov
'14
1:13 p.m.
Am 16.11.2014 11:19, schrieb Eric Kohl:
Hello Love,
I think you are trying to fix a bug at the wrong end. The boolean types
BOOL and BOOLEAN only have, by definition, two valid values: TRUE (aka
1) and FALSE (aka 0). Your 'other' trues (aka 2 to 2^32-1) are illegal
values which must NEVER be assigned to a boolean variable. Otherwise you
accept to break the checks for TRUE.
The problem with this strict definition is,
that we cannot use it, since
it does not match with MS' definition.
MSDN says about BOOL and BOOLEAN:
"A Boolean variable (*should* be TRUE or FALSE)." Should is not must.
Most win32 APIs that return BOOL are described in MSDN with something like:
"If the function succeeds, the return value is *nonzero*."
And there are Windows APIs that return BOOL with values other than 0 and 1.
The defensive approach of avoiding direct comparison to TRUE should be
the best.
Quoting Raymond Chen: "Checking for equality against TRUE is asking for
trouble."
Developers MUST be VERY STRICT when assigning values
to a boolean
variable. They HAVE to make sure that the assigned values are either
TRUE or FALSE. IMO other programmers have the right to rely on the fact
that a function, which returns a boolean value, only returns the values
TRUE or FALSE and NEVER returns any other value. Code like "if
(ReadFile(...) == TRUE)" is absolutely OK and MUST work as the
programmer expects!
That might be ok for ReadFile, where MSDN explicitly says it
returns
TRUE on success.
But it's not necessarily ok for other APIs.