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

[Kazunobu Kuriyama]

David Ayers wrote:

<snip>

> I don't think we are in disagreement.  My point is, in C truth semantics: 

Yes, I am not against your proposal itself, and I think I understand 
your point.

> int i = 256;
> if (i)
>
> will be evaluted as true.  But
>
> if ([[NSNumber numberWithBool: i] boolValue])
>
> will return the 'NO' BOOL instance and be evaluated as false. 

I agree the result appears counter-intuitive, and that in many cases, it 
may differ from
what we (carelessly) expect.  But whatever our intention may be, the 
higher bits of the
variable i are to be truncated because this is what the C language 
specification promises
when an interger variable is converted into a one having a narrower bit 
pattern.  No one
is blamed for this.

Perhaps, we are inadvertently influenced by the word 'BOOL'.  For 
example, if I wrote

void func(unsigned char c)
{
   if (c) printf("YES");
   else printf("NO");
}

int main(void)
{
   int i;
   func(i = 256)
   return 0;
}

and posted somewhere, writing 'That non-zero is true is false', then you 
would definitely
laugh at me, ignoring the post, or reply to me, 'Why don't you read your 
C book again?' if
you felt a pity on me.

On the other hand, what if I replaced void func(unsigned char c) with 
void func(BOOL c)?
In this case, someone would be likely to track down the source of the 
problem in favor of me.
And another thread similar to those we have recent days begins...

> You can't rely on the C truth value (i.e. rely on the "true" value or 
> 256) to be passed through the method invocation which converts the 
> integer to unsgnied char in this case '0' and expect to have get the 
> 'YES' BOOL value as the parameter in the implementation of 
> +numberWithBool. 

If I'm allowed to paraphrase your intention into something else, I'd say:
You can rely on the C truth value, BUT you must be careful when you use 
a method/function invocation
involving one or more BOOL variables or a cast to BOOL.  In ObjC, BOOL 
is usually defined to be a shorter
integer type, and hence the integer promotion/conversion rules of C also 
applies to it without any exception.
Therefore, when usign BOOL, you should be careful so that no unexpected 
promotion/conversion will happen.

If your argument made clear the distinction between the C truth value 
and the integer promotion/conversion,
I would never complain.   I think these two are completely different 
issues and hence believe we need
some argument on this to establish a firm foundation for the new coding 
standard.

In fact, your propose looks fine to me, but I couldn't understand the 
rationale.  If you could make your
argument clear in terms of the point above, it would make the argument 
stronger enough shut me up. ;-)

> IOW: C "truths" (i.e. C truth semantice) aren't implicitly converted 
> to BOOL YES/NO.  The conversion must be made explict. 

I can't be against this! :-)

Cheers,
Kazunobu Kuriyama