In my unit testing I was looking at some boundary conditions and my tests kept failing. I tracked it back to enumerating through an index set when its indexes extend all the way to NSNotFound-1 (the maximum legal value per the documentation).
Using this test code:
// Create an index set with NSNotFound-5, NSNotFound-4, NSNotFound-3,
// NSNotFound-2 and NSNotFound-1
NSIndexSet *testSet = [NSIndexSet indexSetWithIndexesInRange:
NSMakeRange( NSNotFound - 5, 5 )];
NSLog( @"Index set with %lu entries: %@", (unsigned long) testSet.count, testSet );
NSLog( @"NSNotFound is %lu and NSNotFound-1 is %lu", NSNotFound, NSNotFound - 1 );
__block int count = 0;
[testSet enumerateIndexesUsingBlock:^(NSUInteger idx, BOOL *stop) {
NSLog( @"- %lu", (unsigned long) idx );
++count;
}];
NSLog( @"The count is %d", count );
In the log output I get:
Index set with 5 entries: <NSIndexSet: 0x10057f890>[number of indexes: 5 (in 1 ranges), indexes: (9223372036854775802-9223372036854775806)]
NSNotFound is 9223372036854775807 and NSNotFound-1 is 9223372036854775806
- 9223372036854775802
- 9223372036854775803
- 9223372036854775804
- 9223372036854775805
The count is 4
I tried this on my Mac and on the iOS simulator and get the same results (other than the actual values of NSNotFound, depending on 32 bit or 64 bit).
This made me think maybe I was reading the documentation wrong. Am I doing something wrong or is this an Apple bug?
Well it looks like I have confirmation that it is/was a bug. I put in a bug report and heard from Apple that it is fixed in the latest OS X Yosemite Developer Preview and Xcode Preview. I downloaded it and it seemed to work as expected from the documentation.
I suspect they had to change one line of code so asked if they would be patching the current or previous versions of Xcode but I have not heard and I am not holding my breath.