Question

I have a CoreData entity with an NSNumber property (an Integer 16 in the model). I have the following code:

NSLog(@"raw changeAmount=%d", changeAmount);

NSNumber *changeNumber = [NSNumber numberWithInt:changeAmount];

NSLog(@"number changeAmount=%d = %@", [changeNumber intValue], changeNumber);

record.changeAmount = changeNumber;

NSLog(@"new changeAmount=%d", [record.changeAmount intValue]);

changeAmount is an int with the value 123000 when I run my test. When I test on iOS 4, everything works properly and prints out 123000. However, if I run this same code on iOS 5, the value is something like -8072 or -25,536. Like so:

raw changeAmount=123000
number changeAmount=123000 = 123000
new changeAmount=-8072

What the heck happened between iOS4 and iOS5 that is causing this? Have I been setting my NSNumber properties incorrectly this entire time?

It doesn’t appear to be an integer size issue, because I changed the model to use integer 32 (which it should have been all along) and it’s still happening. So we aren’t getting integer overflow or anything.

Answer 1

I have just run this code in CodeRunner

size_t shortSize = sizeof(short);
size_t intSize   = sizeof(int);

short short123000 = 123000;
int   int123000   = 123000;

NSString *format = @"\nshortSize       => %d\n"
                   @"int Size          => %d\n"
                   @"short with 123000 => %d\n"
                   @"int with 123000   => %d";

NSLog(format, shortSize, intSize, short123000, int123000);

which results in:

shortSize         => 2  
int Size          => 4  
short with 123000 => -8072  
int with 123000   => 123000

NB The size is in bytes and there are 8 bits in a byte thus 2*8 = 16bit and 4*8 = 32bit.

I had similar issues with some of the apps I work on. It would appear that CoreData has become a bit stricter about enforcing its types. I was caught out by it to but I should have been more vigilant about what I was doing, if Apple had changed their API so that it did not behave as it is supposed to people would complain but when the API is changed to do what it advertised in the first place it’s just unfortunate and likely to catch people out.

As you can see this is a simple integer overflow so if you know the range your working in you can easily fix this up.