I must have misinterpreted the kata then, given by the examples it looked like it wanted the solution with the pairs the least distance apart...

This is the description I'm seeing...

sum_pairs([10, 5, 2, 3, 7, 5], 10)

^-----------^ 5 + 5 = 10, indices: 1, 5

^--^ 3 + 7 = 10, indices: 3, 4 *

* entire pair is earlier, and therefore is the correct answer

== [3, 7]

is [3, 7] wrong in that case?

the examples have shown pointers with possible solutions, I must admit it looked misleading seeing the second example with the same-length pairs

this solution would not work with this case if you go for the shortest distance:

print(sum_pairs([1, 2, 10, 7, 5, 8, 9, 3, 6, 4, 12], 10))

actual: [2, 8]
expected: [6, 4]

The examples given have random order of numbers. The requirements say to return the pair with the shortest distance, this solution does fulfill that requirement.
It's a very nice solution regardless.

my test cases are constantly crashing with free/malloc issues... x_x

I suppose given that this is a 8kyu kata a division by zero special case would be too much, nice beginners kata though.

consider this:

a = [1,2,3,4,5,10,11,12,13]
b = [1,2,3]

a = [1, 10, 11, 12, 110, 111, 112]
b = [1]

This kata could have been improved by adding a special case where the text does not contain letters.

Some of these tests I really do not understand..

There's the first test under 'Show number in upper case hexidecimal format', which initializes the Hex with initial value 15, that plus 1 and plus 16, resulting in 32. Then the toString method is called to get the hex value, which I figured would return 0x20 due to 32 / 16..

Yet the test's requirements is: Expected: 0xF, instead got: 0x20
Either I don't know what hexadecimal is or that test isn't right; The entered plus/minus values are always integers/numbers, so there would be no need to parse as no issue arises from that..

you can also use a regex to remove any non-alphanumeric character from the string; (Case: http://stackoverflow.com/a/5214668/1125351)

Your if case can only remove the characters that you have given in your case while there might be several other special characters that could be in use.

the server-side test cases are missing out on numbers above 10 or below 0 within the array; the case [1,-9] where the negative number is at the very end doesn't do the challenge justice and those finishing this exercise might be miss out on that issue.

the array could also include non-number elements, which could influence the outcome.