title: NSString hash collision doesn't mess up NSDictionary
body: <p>Run this code in the debugger and stop afterward (I'm in the iOS 7 simulator in Xcode 5.0.1).</p>
  
  <pre><code>NSString *nsStr = @"/Users/123456789012/Library/Application Support/iPhone Simulator/7.0/Applications/94F31827-6DAD-4BD5-AC91-B215176265E1/Documents/libraries/shared/17517_abPub/OEBPS/indexes/Index.sqlite";
  NSString *nsStr2 = @"/Users/123456789012/Library/Application Support/iPhone Simulator/7.0/Applications/94F31827-6DAD-4BD5-AC91-B215176265E1/Documents/libraries/shared/16583_abPub/OEBPS/indexes/Index.sqlite";
  NSUInteger form1 = [nsStr hash];
  NSUInteger form2 = [nsStr2 hash];
  
  NSMutableDictionary *dict = [[[NSMutableDictionary alloc]init]autorelease];
  [dict setObject:@"foo" forKey:nsStr];
  
  id foobar = [dict objectForKey:nsStr2];
  </code></pre>
  
  <p>Note that <code>form1</code> and <code>form2</code> are the same.  We have a hash collision.  Also note that <code>foobar</code> is <code>nil</code>.  The hash collision does not faze <code>NSDictionary</code>.  Why is this?  Does anyone know what Apple is doing to survive hash collision in their dictionary / what some good strategies are for this?</p>
  
  <p>EDIT: For reference, <a href="https://gist.github.com/fphilipe/3413755" rel="nofollow">here</a> is more detail on NSString hashing.  Apparently the method only looks at the first, middle, and last 32 characters; anything else in the string doesn't matter.</p>