[ros-dev] Replacing unsafe TRUE comparisons (Following Re: bool => BOOL)

Timo Kreuzer timo.kreuzer at web.de
Sun Nov 16 13:13:42 UTC 2014


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.





More information about the Ros-dev mailing list