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

[David Ayers]

Pascal J.Bourguignon wrote:
> David Ayers writes:
>
> > Due to the standard C conversion rules, which may truncate the higher 
> > order bytes, code must insure to explicitly convert any C truth values 
> > into the valid BOOL values if either YES or NO.
>
>
> No. Code must  insure to explicitly convert any C  scalar value into a
> truth value, in order to be able to generate a valid BOOL value.
>
> int a_value=4*256;
> unsigned char  random_value = a_value;      /* THIS IS NOT A TRUTH VALUE!!! */
> unsigned char  my_boolean   = (a_value!=0); /* must be explicit! */

I guess we still have a terminology issue here.  I've been (mis?)using 
the term "C truth value" to mean expressions that an if/while/for test 
would evaluate to true.  In this sense, a_value qualifies for this 
constraint.  So would s/C truth values/expressions that C tests would 
evaluate to true/g be fine? Or rather to incorporate your suggestion:

Code must convert C expressions into a valid BOOL value of either YES or 
NO.  It may do this by relying on the result of C comparison 
expressions.  This must be done to avoid incorrect evaluation due to 
type conversion rules and allows explicit tests with YES.

> > I'd say uninformed rather than careless, but maybe some sane C 
> > programmer can offer a patch to our coding conventions to educate us 
> > carelessly insane ObjC developers, by correctly and clearly stating and 
> > demonstrating the issue.
>
>
> void PleaseWrite(bool isBetter,void* pointer,int value);
> {if((!isBetter)&&(pointer!=NULL)||(value==0)){ print("Right!\n");}}
> int  value;
> bool isCorrect=(value!=0);
> value=isCorrect?1:0;

This snippet shows some conventions that will produce correct code.  I'd 
like an example like Nicola's to show how not following this particular 
convention leads to wrong behavior.  It's important to differentiate 
between arbitrary style conventions and unsafe code.  The reason why I 
think this case is so special is documented by this thread where 
experienced developers relied on unsafe code, because they felt they 
needn't follow strict stylistic constraints in their code.

(BTW: Is there a technical reason why
- (!isBetter) is better than (isBetter != NO)
- (pointer!=NULL) is better than (pointer)
- (value==0) is better than (!value)
in that particular 'if' statement?)

> > I'd appreciate if we could get back to the discussion on whether we 
> > should have a public macro to warn/assert about the correct values of 
> > BOOL parameters and return values, so that other carelessly insane 
> > developers may be educated.
> >
> > I have no objections to stick with isYES(), but maybe a simple 
> > is()/_is() may be less bulky than my previous alternatives and won't be 
> > as hard to parse in comparisons involving NO.  I'd be in favor of 
> > emitting a warning and "BOOLifying*" by default and possibly raising 
> > with NDEBUG defined (i.e. when compiled with debug=yes).  If some think 
> > this is too harsh because there are too many carelessly insane 
> > developers that have produced legacy code that doesn't take care to 
> > convert, I'd be fine with only emitting warnings.
>
>
> > * comparing with "!= NO" and returning the result.
>
>
> Perhaps it could be enough to check BOOL parameter input into the API.

Given the fact that -boolValue is documented to potentially "misbehave", 
I'd say that it deserves special treatment.  But I agree that testing 
all (esp. seldom overwritten) methods which return BOOL (isKindOfClass:) 
is overkill.  Otherwise I'm fine with anything that includes testing 
parameters and ... only testing -boolValue return values to testing 
non-standard is/has/responds/does/... methods, or simply leaving it up 
to the primary maintainer.

Cheers,
David