> Quite simply, there isn't enough memory available in the address space to
> ever create a useful array containing NSIntegerMax number of objects.
Thx to all - very interesting, and my mind is set at ease. (I am mostly worried
about whether there are any practical gotchas lurking behind the ha
Er, I mean 2**67 bytes. My brain was stuck on 32 bit pointers.
On Jul 20, 2013, at 15:30 , Quincey Morris
wrote:
> or about 2**35 bytes
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments t
There's no mistake. There are several things going on here.
One is that C is a bit funny about compile-time resolution of constants outside
the signed (int or long) range, which makes it desirable to avoid having a
constant outside the range. Otherwise, unsigned constants may turn into signed
c
On Jul 21, 2013, at 0:06, Matt Neuburg wrote:
> Isn't there a type mismatch here? It seems to me that NSNotFound ought to be
> a value *outside* the possible range NSArray index values - which it would
> be, if NSNotFound were NSUIntegerMax, or if NSArray's indexes were of type
> NSInteger. As
On 20 Jul 2013, at 23:06, Matt Neuburg wrote:
> On iOS, NSNotFound is defined as NSIntegerMax. However, the index of an
> NSArray, which is a case where you'd often want to use NSNotFound (e.g.
> indexOfObject:), is of type NSUInteger.
>
> Isn't there a type mismatch here? It seems to me that
On iOS, NSNotFound is defined as NSIntegerMax. However, the index of an
NSArray, which is a case where you'd often want to use NSNotFound (e.g.
indexOfObject:), is of type NSUInteger.
Isn't there a type mismatch here? It seems to me that NSNotFound ought to be a
value *outside* the possible ran
