Re: [RFA]: BOOL coding standards (Was: Problemwith+numberWithBool:?)

[David Ayers]

During private discussion with Richard, he pointed out to me why the 
result C tests *cannot* be safely interpreted as BOOL values.

C tests evaluated by if/while/for take into account the full size of 
their arguments.  Assigning a value of a type larger than char to a BOOL 
(or providing such a value as an argument to a method/function expecting 
a BOOL) ignores all higher ordered bytes.

IOW
[NSNumber numberWithBool: (i=256)]; => NO
[NSNumber numberWithBool: (i=512)]; => NO
[NSNumber numberWithBool: (i=768)]; => NO
...
i.e. if the C truth value was 'short', we have 255 values that would 
potentially be false negatives, for 'int' it would already be 16.777.215 
(2^(8*3)-1).

Therefor:
[NSNumber numberWithBool: isupper(someChar)];
where isupper can be replaced with any other function returning an int, 
is unsafe.

This clearly shows that my previous assumption that  C truth values may 
be used for BOOL parameters is plainly false.  So let my turn my view 
point by about 180 degrees :-/.

- The only valid values for BOOL shall be YES and NO.
- Any method/function returning BOOL *must* return YES or NO.
- There is no way that we can detect faulty conversions by the caller 
within the callee, therefor it's the callers responsibility to provide a 
true BOOL and he may *not* rely on C truth semantics.
- There is a technical reason for asserting that a BOOL must be YES or 
NO, as it helps uncover misbehaving callers.

Our example must be written as:
[NSNumber numberWithBool: (isupper(someChar) != 0)];

Therefore, I don't see any practical benefit in testing "!= NO" instead 
of "== YES" anymore.  I'd even go so far as to say that using "!= NO" 
gives a false sense of robustness.

I retract my offer (unposted patch) to use isYES() to test or implicitly 
BOOLify parameters or return values.

I have no more objections on asserting YES/NO values for BOOL:s or 
warning about invalid values.

I thought isYES() would be a good name for a '== YES' replacement.  I 
don't think isYES() is a good name for general BOOL value 
assertion/warnings.

I'd prefer something more explicit (but maybe too bulky) like 
GSCheckBOOL(), GSAssertBOOL() ...???

I think it should be used test parameters.  I think it may be used to 
test return values, but care should be taken to insure readability.  I 
don't mind if it BOOLifies illegal values by default to avoid breaking 
too much code currently working with false assumptions.

Thoughts?

Cheers,
David

PS: Thanks again, Richard for the extra effort to clarify this.