IOS5 CoreData object displaying invalid NSNumber value works on iOS4

Question

I have a CoreData object with the NSNumber property (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 a value of 123000 when I run my test. When I test on iOS 4, everything works correctly and prints 123000. However, if I run the same code on iOS 5, this value is approximately -8072 or -25.536. For instance:

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

What the hell happened between iOS4 and iOS5 that causes this? Have I set my NSNumber properties incorrectly all this time?

It is not an integer size problem, because I changed the model to use the integer 32 (which should have been all the time), and this is still happening. Thus, we do not get integer overflow or anything else.

Answer 1

I just ran 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); 

that leads to:

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

NB . The size is in bytes and 8 bits per byte, so 2 * 8 = 16 bits and 4 * 8 = 32 bits.

I had problems with some of the applications I'm working on. It would seem that CoreData has become a little more stringent in enforcing its types. I was caught by this, but I had to be very vigilant about what I would do if Apple changed its API so that it did not behave as expected that people would complain, but when the API was changed to do the fact that he is advertised in the first place is simply unsuccessful and is likely to catch people.

As you can see, this is a simple integer overflow, so if you know the range you work in, you can easily fix this.