Re: floatValue of nil NSNumber unreliable (was Re: Bug or feature?)
Re: floatValue of nil NSNumber unreliable (was Re: Bug or feature?)
- Subject: Re: floatValue of nil NSNumber unreliable (was Re: Bug or feature?)
- From: Ali Ozer <email@hidden>
- Date: Tue, 14 Feb 2006 10:44:52 -0800
Float is not an integer scalar, so the 0.0 return is traditionally
not guaranteed from a message send to nil. Basically id, pointers,
int, BOOL, unichar are OK; float, double, long long, and structs aren't.
However recently things were changed for the better:
http://developer.apple.com/documentation/MacOSX/Conceptual/
universal_binary/universal_binary_tips/chapter_5_section_22.html
...and this sounds like the original complaint (which is Xcode 2.2,
on 10.4.4) should have been addressed. However I am not sure of the
state of things on PPC, and I am not clear on the seemingly
contradictory statements:
> With the release of Xcode 2.2, Objective-C messages sent to a nil
object behave the same on both PowerPC and Intel-based Macintosh
computers
and
> On Intel-based Macintosh computers, messages to a nil object
always return 0.0 for methods whose return type is float, double ...
On PowerPC Macintosh computers, all of the same conditions apply
except that these messages usually return nil rather than always
return nil
Using the last sentence as a guideline, it's probably good to
continue avoiding sending messages potentially invalid returns to
nil. In the meantime there's a radar asking for clarification on this
page.
Ali
On Feb 14, 2006, at 10:31 AM, M. Carlson wrote:
From this Apple statement:
"The Objective-C runtime assumes that the return value of a message
sent to a nil object is nil, as long as the message returns an
object or any integer scalar of size less than or equal to sizeof
(void*)."
Would it be fair to conclude that a float value takes up more stack
space than an integer, and thus the "odd" behavior? I.e., it's only
zeroing out space enough for an integer, not a float value, so
whatever's sitting beyond the integer on the stack is being
returned as part of the float value?
--M
From: Daniel Jalkut <email@hidden>
To: M. Carlson <email@hidden>
CC: email@hidden
Subject: floatValue of nil NSNumber unreliable (was Re: Bug or
feature?)
Date: Tue, 14 Feb 2006 13:21:55 -0500
Interesting. I just took your snippet and also reproduced funny
behavior (identical config to yours, incidentally).
What's interesting is the "random number" seems to correspond to
the last "real float NSNumber" used.
For instance:
float fval=0.0;
NSNumber *aNumber=nil;
NSNumber *secondNumber = [NSNumber numberWithFloat:0.5];
fval=[aNumber floatValue];
NSLog(@"fval is %f",fval);
fval is always 0.5.
It sounds like a bug to me. Maybe somebody from Apple will have an
opinion about this.
Daniel
On Feb 14, 2006, at 1:14 PM, M. Carlson wrote:
This is using Xcode 2.2, OSX 10.4.4, PM G5 2GHz x 2. When I run
this, I get random numbers in fval. This came about when I was
retrieving a value from an NSDictionary, but there was no entry
in the dictionary for the key I was using. I ended up getting
wild values for fval, and finally boiled it down to this little
snippet, which seems odd to me.
So, am I misunderstanding something about Cocoa, or is it some
Xcode setting I'm supposed to be using so I get 0 back?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden