The problem exhibited itself under certain circumstances. That led me to investigate and discover this line (in pseudocode):
if ([object getProperty] > [anotherObject getProperty]){
Years ago, this line was correct, because in this particular object's getProperty used to return a primitive such as an int or NSInteger (I can't remember which).
But at some point getProperty was changed so that it returned an NSNumber, which is an object rather than a simple value.
The line should have been updated to (and has been now):
if ([[object getProperty] integerValue] > [[anotherObject getProperty] integerValue]){
Of course I should have searched the source for 'getProperty' and updated accordingly but this particular line escaped. It went unnoticed. The compiler didn't complain, and everything still seemed to work.
If a tree falls in a forest...... If a bad line of code appears to work under testing and no-one reports a problem, is it still a bug?
It didn't always work though. Under certain circumstances that particular thing went screwy (no crash, no exception, just odd results sometimes). But not randomly. It worked or didn't work predictably, depending on the circumstances.
I can't find confirmation of this but it seems from what I've observed that
(NSObject > NSObject)
returns true or false depending on the order that they were created. I'm assuming that the comparison is being made using the object's address (pointer) treated as a numeric value. This makes sense because declaring NSObject *myobject declares myobject as a pointer, which is some kind of primitive, known to contain a memory address.
A simple experiment seems to bear this out.
NSNumber *number1 = [NSNumber numberWithInt:2];
NSNumber *number2 = [NSNumber numberWithInt:10];
NSLog(@"number1: %p, number2: %p", number1, number2);
if(number1 > number2){
NSLog(@"number1 is greater than number2");
}
else{
NSLog(@"number2 is greater than number1");
}
returns:
NumberTest[89819:23978762] number1: 0x7312659ea1d74f79, number2: 0x7312659ea1d74779
NumberTest[89819:23978762] number1 is greater than number2
It's interesting that the objects seem to be allocated going backwards in memory in this example. I assume that allocation of memory is not predictable, but that there would be some general sequence to it, backwards or forwards.
I'm obviously pleased to have found and fixed a problem in this app. But more than anything this has amused and interested me.
If you have anything to contribute on this subject, leave it in the comments.
