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 constants, and vice versa. (I can never remember the exact scenario, so that's why I'm waving arms a bit. But it's a known C quirk.)
Another is that it's useful for NSNotFound to have one value that can be used in either an signed or unsigned context. That means it has to lie in non-negative signed integer range, and the only practical value meeting those conditions is NSIntegerMax. Lastly, NSUIntegerMax isn't *outside* the unsigned integer range, it's the last value inside it. However, limiting the range even to half of the theoretical maximum isn't a problem. It isn't possible to have a Cocoa collection of even NSIntegerMax elements, because the memory addressing range isn't big enough to record that many pointers, let alone the objects pointed to. (You'd need NSIntegerMax * 8 bytes for the pointers, or about 2**35 bytes.) There was a thread about this recently, and I think the take-away is: -- Having NSNotFound==NSIntegerMax is only a problem in the context of things like sparse arrays that need a full 64 bits of indexing. If you implement such a construct, you'd better stay away from using NSNotFound with it, but there's nothing like that (AFAIK) in Cocoa itself. -- The real difficulty with NSNotFound is that it's architecture dependent, which means you need to be very careful about NSArchiving it in documents shared between 32- and 64-bit architectures. On Jul 20, 2013, at 15:06 , Matt Neuburg <m...@tidbits.com> 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 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 thing are, when you call indexOfObject: and test the result > against NSNotFound, you could be getting the wrong answer; if that index > happens to be NSIntegerMax (which is only halfway through the available > unsigned indexes), it will seem to be NSNotFound when in fact it is an actual > index. > > I must be wrong about this, since Apple wouldn't make such a basic mistake. > So what's *my* mistake? Thx - m. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
