Bug #4437
closed
IntHashSet.copy()
100%
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.
Updated by Michael Kay over 4 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.
Updated by O'Neil Delpratt about 4 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
.