On Jun 12, 2013, at 00:11 , Oleg Krupnov <oleg.krup...@gmail.com> wrote:
> I've just been shocked to find out that NSNotFound is defined by the > framework as NSIntegerMax, that is maximal value of *SIGNED* integer, > which in 64 bit architecture is 0x7fffffffffffffff. > > I used to think that it should be NSUIntegerMax, that is the maximal > value of *UNSIGNED* integer, corresponding to 0xffffffffffffffff. > > It had to be so because NSNotFound value is used in many places of the > system framework for working with array indexes, for example, > -[NSArray indexOfObject:] returns unsigned NSUInteger indexes, *BUT* > it returns NSNotFound if the element is not found. > > But NSNotFound should be a valid index in the middle of possible > unsigned integer range! It means that even though the NSArray allows > NSUIntegerMax of elements, you can actually use only NSIntegerMax > elements, because starting from NSIntegerMax you will get screwed up > by things like indexOfObject: > > How come? It's the only extreme-ish compile-time constant that's representable unambiguously in both signed and unsigned expressions. C has funny rules for conversions in compile-time expressions, so that makes using (for example) 0xFFFFFFFFFFFFFFFF treacherous in other ways. As long as you're aware of it, it's not a major problem in the NSArray case, since it would be extremely rare to actually want array indexes that don't fit into 63 unsigned bits, as opposed to 64. In particular, there isn't enough address space to create a NSArray containing even NSIntegerMax pointers. The easiest conceptual adjustment here is to think of NSUInteger as a 63-bit number, not a 64-bit number. Actually, the "weird" value for NSNotFound is not really the most treacherous aspect. Far more dangerous is the fact that it's not generally safe to archive (i.e. use the NSCoder protocol on) NSNumber objects whose value represents NSNotFound, because the value is architecture dependent. If you archive a 64-bit NSNotFound, it's no longer NSNotFound when unarchived on a 32-bit architecture, and vice versa. _______________________________________________ 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
