3

When I attempt to create an NSNumber using the numberWithLongLong with a number greater than -2 and less than 13 it returns a number that is casted as an (int).

I see this if I look at the Xcode debugger after stepping over my line.

NSNumber* numberA = [NSNumber numberWithLongLong:-2]; //Debugger shows as (long)-2
NSNumber* numberB = [NSNumber numberWithLongLong:-1]; //Debugger shows as (int)-1
NSNumber* numberC = [NSNumber numberWithLongLong:12]; //Debugger shows as (int)12
NSNumber* numberD = [NSNumber numberWithLongLong:13]; //Debugger shows as (long)13

To put my problem in context, I am using a long long value for an epoch date that I will end up serializing using BSON and sending across the wire to a webservice. The webservice requires the date to be a java Long.

Thanks in advance

user1556446
  • 33
  • 5
  • Ummm… You do know that `sizeof(int) == sizeof(long)`. Both are 32-bit signed integers. see: http://stackoverflow.com/questions/2107544/types-in-objective-c-on-iphone – Jeffery Thomas Apr 13 '13 at 01:11
  • Additional info you could add to your question: numbers B and C return `"i"` for their `objCType`, whereas A and D return `"q"`. It also happens when you suffix the numeric literals with `LL`, or use `alloc`/`initWithLongLong:`. Did this testing in the debugger on an iPad 3rd gen running iOS 5.1 – Carl Veazey Apr 13 '13 at 01:25
  • What's the problem you are actually having with this? What the debugger shows isn't very relevant compared to what you actually need to do with the `NSNumber` objects. – rmaddy Apr 13 '13 at 01:42
  • @CarlVeazey So, `+numberWithLongLong:` returns an NSNumber object with an `"i"` objCType? – Jeffery Thomas Apr 13 '13 at 01:42
  • @JefferyThomas yes, I did some further testing actually. On iOS 5.1 device and 6.1 sim it returns `"i"`. My Mac running 10.8.3 it returns `"q"`. Also tried `initWithBytes:objCType:` but contrary to convention this returns an NSValue even when called on an NSNumber instance. – Carl Veazey Apr 13 '13 at 01:53
  • @CarlVeazey yeah, I just read rob's answer. That is crazy. I trust NSNumber much less now. – Jeffery Thomas Apr 13 '13 at 01:55
  • 1
    Why does it really matter what size of number is stored internally? I mean, as long as you can say `[number longLongValue]` and get the right value back...why is it a problem that the runtime saves a few bytes? This seems like encapsulation at work, and i don't see yet why it shouldn't be trusted. – cHao Apr 13 '13 at 03:36

3 Answers3

6

You have discovered that NSNumber (actually, its CFNumber counterpart) has a cache for integers between -1 and 12 inclusive. Take a look at the CFNumberCreate function in CFNumber.c to see how it works.

It looks like you can force it not to use the cache by passing your own allocator to CFNumberCreate. You'll need to look at the CFAllocator documentation.

But note that the CFNumberCreate manual says this:

The theType parameter is not necessarily preserved when creating a new CFNumber object.

So even if you bypass the cache, you might not get back an object whose objCType is q (which means long long). It looks like the current implementation will return q but that could change in a future version.

You are allowed to write your own NSNumber subclass if you need to guarantee that objCType returns q. Read “Subclassing Notes” in the NSNumber Class Reference.

rob mayoff
  • 375,296
  • 67
  • 796
  • 848
  • Do you think `long long x = 1; NSValue *number = [NSValue valueWithBytes:&x objCType:"q"];` would work better? Yes, it's a value not a number, but won't the type get preserved? – Jeffery Thomas Apr 13 '13 at 01:51
  • If you want to guarantee that you get an `NSNumber` with an `objCType` of `q`, you can write your own subclass of `NSNumber`. – rob mayoff Apr 13 '13 at 03:04
3

You can use your webservice without concern.

NSNumber wraps a numeric value (of primitive type) as an object. How NSNumber stores that value is not really your concern (but there is a method to find it out), it is an opaque type. However NSNumber does maintain an internal record of the type used to create it so its compare: method can follow C rules for comparison between values of different types precisely.

For integral types the integral value you get back will be exactly the same, in the mathematical sense, as the one you created the NSNumber with. You can create an NSNumber with a short and read its value back as a long long, and the mathematical value will be the same even though the representation is different.

So you can store your integral date value as an NSNumber and when you read it back as a long long you will get the right value. No need to be concerned how NSNumber represents it internally, and indeed that could potentially change in the future.

(At least one implementation of NSNumber can store values as 128-bit integers, which helps ensure correct semantics for signed and unsigned integers. Also I stressed integral types as with the vagaries of real numbers talking about mathematical exactness is somewhat moot.)

CRD
  • 52,522
  • 5
  • 70
  • 86
1

Wait. I think I know what your asking. Try it this way:

NSNumber* numberA = [NSNumber numberWithLongLong:-2LL];
NSNumber* numberB = [NSNumber numberWithLongLong:-1LL];
NSNumber* numberC = [NSNumber numberWithLongLong:12LL];
NSNumber* numberD = [NSNumber numberWithLongLong:13LL];

BTW: it won't matter what the type of the constant is, it will be coerced into a long long when passed to [NSNumber numberWithLongLong:]

UPDATE

Based on @robmayoff's answer, I don't think NSNumber is reliable for your. How are you packing your BSON? is there a way to use NSValue instead of NSNumber?

Jeffery Thomas
  • 42,202
  • 8
  • 92
  • 117
  • i don't think this will make any difference... compile should always cast int to long long before pass it as argument anyway – Bryan Chen Apr 13 '13 at 01:27
  • @xlc Automatic casting done by the compiler is called coercion. see: http://en.wikipedia.org/wiki/Type_conversion#Implicit_type_conversion – Jeffery Thomas Apr 13 '13 at 01:36