You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
version: v1.3.3 Issue
I've found an issue where Count() may return the wrong count if the BitSet had been copied from another BitSet. It appears that there are some edge cases that had set bits that overflow the length of the copied to BitSet in the last uint64 those will get counted.
I think a solution would be to have the Copy method set the bits that overflow from the copied to count to 0.
This test case makes this obvious, Count() > Len() in the copy and notice how the test that takes a copy of 64 bits from a 72 bitset passes. That is because the copies target count is aligned to a 64 bit boundary so there is no room for the extra set bits from the source copy to pollute the result.
Looks like a simple fix using an existing method at the end of copy. I added cleanLastWord and a non-exhaustive unit test that should be good enough to prove the fix and fails without it.
version: v1.3.3
Issue
I've found an issue where Count() may return the wrong count if the BitSet had been copied from another BitSet. It appears that there are some edge cases that had set bits that overflow the length of the copied to BitSet in the last uint64 those will get counted.
I think a solution would be to have the Copy method set the bits that overflow from the copied to count to 0.
This test case makes this obvious, Count() > Len() in the copy and notice how the test that takes a copy of 64 bits from a 72 bitset passes. That is because the copies target count is aligned to a 64 bit boundary so there is no room for the extra set bits from the source copy to pollute the result.
Test:
Results:
The text was updated successfully, but these errors were encountered: