Project

Profile

Help

Bug #4437

IntHashSet.copy()

Added by Michael Kay almost 2 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Internals
Sprint/Milestone:
-
Start date:
2020-01-22
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
9.9, trunk
Fix Committed on Branch:
9.9, trunk
Fixed in Maintenance Release:
Platforms:

Description

There appears to be a bug in the method IntHashSet.copy(). The new IntHashSet that emerges from the copy appears to have all fields identical to the original except for _mask, and the difference in the _mask value means that existing entries are not found in a contains() call.

This is code that has been stable for years, and it's not obviously unused (though that might turn out to be the case). Perhaps it only happens under rare conditions in terms of the actual map content. The bug was revealed in a new piece of code in 10.0 that makes use of IntHashMap. As it happens, the new code doesn't actually need to invoke copy() at all.

History

#1 Updated by Michael Kay almost 2 years ago

  • Status changed from New to Resolved
  • Applies to branch 9.9, trunk added
  • Fix Committed on Branch 9.9, trunk added

First, I've established that if we copy the _mask field, the broken test case now works OK.

in the 10.0 version, I've added a method IntMap.isMutable() which returns true for those implementations of IntMap that can be modified in-situ; for this particular index, this avoids the need to copy the map in cases where it can be updated in situ.

#2 Updated by O'Neil Delpratt almost 2 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 9.9.1.7 added

Patch applied in the 9.9.1.7 maintenance release.

Please register to edit this issue

Also available in: Atom PDF