Fix underflow in Sift4Common

[Palladinium]

I'm running the Sift4Common distance over results of OCR, which are often quite noisy. I've found some strings in the wild which cause a panic in debug mode, because of a subtraction with underflow.

I haven't actually fixed the bug yet (hence the draft status), but I've added some failing tests for the moment. I'll keep digging to identify the root cause and a fix.

[Palladinium]

From a first look, it seems to me that the overflow occurs due to the optimization at line 100, wherein the two cursors have 1 subtracted from them in advance to account for the 1 that is added later in the loop. Because i can be 0, doing c1 += i - 1 underflows the right-hand side of the assignment.

I tried the easy fix of splitting the line into c1 += i; c1 -= 1;, but because c1 is zero, the overflow occurs anyways.

Ultimately, I think the result of the computation is the same, because the overflowed value gets 1 added to it immediately after, which overflows it back to 0. I can think of two solutions which don't require deviating significantly from the semantics of the original implementation:

• Change the type of c1 and c2 to isize, and cast back to usize when indexing into s1 and s2
• Wrap c1 and c2 in Wrapping, to suppress the panic

I'm not a fan of either, but I don't really see a better option.

[orsinium]

Bring the fix that you see the best fit. If it passes all the tests, I'll be happy to merge. I don't remember the algorithm that well, so I'll trust your judgement.

[orsinium]

Thank you :)