Bug in ExchangeIR/FindRepeat, C and Java versions

[Barf]

While working in IrScrutinizer, I found out that if the IR sequence

Code: Select all

8937,4507,573,573,573,573,573,573,573,573,573,573,573,573,573,573,
573,1667,573,1667,573,1667,573,1667,573,1667,573,1667,573,1667,573,1667,
573,1667,573,573,573,1667,573,573,573,573,573,573,573,573,573,573,573,573,
573,1667,573,573,573,1667,573,1667,573,1667,573,1667,573,1667,573,1667,
573,38743,8937,2267,573,96011,4507,104,1068,782,52,208,26,72327,573,96011,
8937,2267,573,96011

causes the Java version of ExchangeIR/FindRepeat, called RepeatFinder, to misbehave. It will cause the function

Code: Select all

protected boolean equalTimes(int[] t1, int offset1, int[] t2, int offset2, int duration_count) {
   for (int i = 0; i < duration_count; i++) {
                if (!equalTimes(t1[i + offset1], t2[i + offset2]))  
...

to be called with t1 and t2 integer arrays of length 86, offset1 = 68, offset2 = 84, duration_count = 14. As is easily seen, three iterations into the loop, and this will try to access t2 outside of its allocated area, throwing an ArrayIndexOutOfBoundsException. I tried the original C version, and it shows exactly the same behavior, just, as C (C++ really), it does not throw an exception, but just gets "something" (undefined) from memory, and happily computes on that. (With bad luck, segmentation errors may result though.) Since (approximate) equality is tested, likely the function will return false.

The quick fix I will implement in the Java version is just to catch the exception, and return false; it is probably fairly innocent (equality was to be tested).