D'oh, make that ">" instead of "<"... ;)
...jim
On 4/20/15 1:47 PM, Jim Graham wrote:
On 4/20/15 1:37 PM, Jim Graham wrote:
In the needRoom() methods, there is one more potential overflow path. If
the array grows to just under MAX_INT, then "numCoords + newCoords" may
overflow to a negative number and the array would not be grown because
the test in needRoom() would fail to trigger a call to the grow method.
We would still get an AIOOBE in the moveTo/lineTo/etc. routine, but we
would insert the new path type into the types array (and increment
numTypes) before we overflowed the coords array. We'd also bump the
numCoords by a couple of entries before we hit the true end of the
array. After the exception, we'd leave the path in a bad state where it
had a recorded segment type that had no associated data (or partial
data) in the coords array. It would be cleaner to test the "numCoords +
newCoords" for overflow in needRoom(). A simple test of the sum being <
0 should do since both numCoords and newCoords should always be positive
numbers and all pos+pos overflows always result in negative numbers...
I just realized that an overflow/underflow-proof test for the growth of
the coords array would be simply:
if (numCoords < coords.length - newCoords) { grow it }
since coords.length is always >= 0 and newCoords is always a small
non-negative number so there is no overflow or underflow there...
...jim
