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: "M. Carlson" <email@hidden>
- Date: Tue, 14 Feb 2006 18:46:34 +0000
On Tue, 14 Feb 2006 18:40:13 Martin Hairer wrote:
"on PowerPC based machines the return value is undefined"
... which begs the question: Why doesn't it / can't it simply return 0 like
it should?
--M
From: Martin Hairer <email@hidden>
To: M.Carlson <email@hidden>
CC: CocoaDev list <email@hidden>
Subject: Re: floatValue of nil NSNumber unreliable (was Re: Bug or feature?)
Date: Tue, 14 Feb 2006 18:40:13 +0000
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?
No, a float takes up 32 bits, which is the same as an integer. Since the
docs say
that such a message only usually returns 0 on PowerPC machines (unless the
return value is an ObjC object), the observed behaviour is not tremendously
surprising.
Of course, one may wonder what the word "usually" means in this context. It
seems
to me that this sentence could just as well have been replaced by something
like
"on PowerPC based machines the return value is undefined", which would have
been
less misleading. Regards,
Martin
HairerSoft
http://www.hairersoft.com/
_______________________________________________
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