Open ITR13 opened 3 months ago
Which means that setAll is setting the bits of the set differently than how initFull sets them.
Would you agree that the solution is to make setAll()
and unsetAll()
only set bits from 0..self.bit_length
? Currently these set all masks which means 1 full mask of 64 bits being set in the code above instead of only bits 0..19.
I just wanted to see if others agree before making any changes.
After looking at the DynamicBitSetUnmanaged code, I think that there are 2 problems. The first is that setAll() shouldn't change the padding bits. And second is that iterator() shouldn't include padding bits.
After looking at the DynamicBitSetUnmanaged code, I think that there are 2 problems. The first is that setAll() shouldn't change the padding bits. And second is that iterator() shouldn't include padding bits.
Either change would fix my issue, I was leaning more towards setAll not changing the padding bits because initFull already had that behaviour. And I was unsure if changing the iterator to verify the length might impact performance.
I'm new to zig though, so I trust everyone elses judgement on this matter ^^
I think its definitely correct to change setAll() since it says in the 'masks' field doc comments
the padding bits must be zeroed .
In my PR yesterday I changed iterator() to skip the padding bits. But now, I think that shouldn't be necessary since the padding bits should never be set. And if the user sets them, thats on them. This would make count() and iterator() consistent again whether or not any padding bits are set. So I'm going to revert the iterator() changes from my PR.
Zig Version
0.13.0-dev.75+5c9eb4081
Steps to Reproduce and Observed Behavior
Code
Running the following program:
Has the following output:
Which means that setAll is setting the bits of the set differently than how initFull sets them. Alternatively it could be an issue with the iterator going outside the range of bit_length.
Other testing done
Expected Behavior
The following output: