dcapwell commented on code in PR #264:
URL: https://github.com/apache/cassandra-accord/pull/264#discussion_r2624128289
##########
accord-core/src/main/java/accord/utils/SmallBitSet.java:
##########
@@ -40,29 +40,50 @@ public long bits()
return bits;
}
+ private static long bitSafe(int i)
+ {
+ validateIndex(i);
+ return bit(i);
+ }
+
+ private static void validateIndex(int i)
+ {
+ if (i >= 64 || i < 0)
+ throw new IndexOutOfBoundsException("Unable to access bit " + i +
"; must be between 0 and 63");
+ }
+
+ @Override
public boolean set(int i)
{
- long bit = bit(i);
+ long bit = bitSafe(i);
boolean result = 0 == (bits & bit);
bits |= bit;
return result;
}
@Override
- public void setRange(int from, int to)
+ public void setRange(int fromInclusive, int toExclusive)
{
- bits |= ~(-1L << to) & (-1L << from);
+ validateIndex(fromInclusive);
+ Invariants.requireArgument(fromInclusive <= toExclusive, "from > to
(%s > %s)", fromInclusive, toExclusive);
+ if (fromInclusive == toExclusive)
+ return;
+
+ bits |= (-1L >>> (64 - (toExclusive & 63))) & (-1L << (fromInclusive &
63));
}
+ @Override
public boolean get(int i)
{
+ if (i >= 64) return false;
Review Comment:
my argument is that read methods shouldn't IIOBE and should return the
negative case as it simplifies the calling logic (would have to update caller
to find the capacity and always make sure to avoid crossing it).
`get` isn't the strongest argument for that, but `nextSetBit` i feel is.
Having every loop check if `nextSetBit` returned the last element pushes this
to every caller and adds clutter all over.
`accord.utils.SortedArrays#fromSimpleBitSet`
```
for (int i = bitSet.firstSetBit(); i >= 0 ; i = bitSet.nextSetBit(i + 1))
```
`accord.coordinate.AbstractCoordination#inflight`
```
for (int i = expectingReply.nextSetBit(0) ; i >= 0 ; i =
expectingReply.nextSetBit(i + 1))
```
All these examples are unsafe if the read apis throws IIOBE and really
expect out of bounds to return negative case; this is the common assumption
throughout the current usage.
We spoke before in my previous patch and you were not a fan of the `get`
method having different semantic from `nextSetBit`, so returning the negative
case keeps the read logic simple/safe for callers
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
