Another interesting thing I've seen with some compilers is when a bit flag
is defined with a signed type:
short someflag : 1;
a value of it being set may be -1 rather than 1, so the only way to compare
it according to how you want it to work is by comparing it against 0 in some
way:
if (!someflag) ...
if (0 == someflag) ...
if (false == someflag) ...
if (0 != someflag) ...
if (false != someflag) ...
After all, zero is always zero, but true-ness can be anything else, unless
you're talking probability.
On 11/21/2008 8:51 AM, "Michael Ash" <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 21, 2008 at 9:13 AM, Ken Thomases <[EMAIL PROTECTED]> wrote:
>> Next, even if you did want to construct an NSNumber from it, it's not a
>> BOOL. So +numberWithBOOL: wouldn't be appropriate. Any non-nil object
>> pointer would result in a true-valued NSNumber, even if [temp
>> objectForKey:@"BBLMColorsSyntax"] had given you a false-valued NSNumber.
>>
>
> Wandering off the track a bit, but I think this is interesting....
>
> It's actually not true that any non-nil object pointer will result in
> a true-valued NSNumber. BOOL is not a true boolean yes/no type, but
> rather it's just a signed char. This means that when you assign, pass,
> or return a different numerical or pointer type in a place where BOOL
> is expected the compiler will simply chop off the top bits to make it
> fit. So if the last eight bits of your pointer all happen to be 0
> (which is not that unlikely!) then your BOOL will be false instead of
> true.
>
> This can bite you if you try to take shortcuts with comparisons. For example:
>
> - (BOOL)isNotNil:(id)obj {
> return obj != nil;
> }
>
> Pretend for a moment that this method is not actually completely
> pointless. So you say, but any non-nil value for 'obj' is always true,
> so I can remove the comparison and just write this:
>
> - (BOOL)isNotNil:(id)obj {
> return obj;
> }
>
> Now you've set yourself up for a nasty intermittent failure. This will
> work correctly, *most* of the time. But on a significant percentage of
> non-nil 'obj' values, you'll get NO back.
>
> Yeah, I did this once (with a less-pointless method, of course) and it
> bit me. Fun times debugging that....
>
> Mike
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
