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

[Manuel Guesdon]

Hi,

On Sat, 07 Feb 2004 11:26:18 +0100 David Ayers <address@hidden> wrote:

 >| 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.

Right, I've thought about casting but not this point. I haven't tested but I 
think 
compiler will emit a warning in such a case.



 >| 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.

OK

 >| - Any method/function returning BOOL *must* return YES or NO.

OK.

 >| - 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.

OK.


 >| - There is a technical reason for asserting that a BOOL must be YES or 
 >| NO, as it helps uncover misbehaving callers.

OK.


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

OK.


 >| 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.

Finally OK.


 >| 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() ...???

Could you explain problems if using IsYes for assertion/warning ? I'm not sure 
we'll get quickly the reflex of adding GSCheckBOOL() :-)


Manuel

-- 
______________________________________________________________________
Manuel Guesdon - OXYMIUM <address@hidden>
14 rue Jean-Baptiste Clement  -  93200 Saint-Denis  -  France
Tel: +33 1 4940 0999  -  Fax: +33 1 4940 0998