The generated machine code contains zero calls to runtime.panicIndex since all index calculations are safe, and this can be proven easily.
As a bonus, the code generator should recognize that the pattern parts[n - x] appears repeatedly with varying small constants for x. There is no need to calculate the expression 16 * n repeatedly in lines 30 to 33.
What did you see instead?
go tool objdump -s joinCambridge contains 7 calls to runtime.panicIndex.
The text was updated successfully, but these errors were encountered:
I don’t think the request is correct. 2+2*len(elements) might overflow, so the bound checks are actually required.
Damn, I didn't think of that. On a 32-bit platform an overflow is entirely possible. On a 64-bit platform with enough virtual memory, you would only need 67 million bars of 256 GB RAM each, which is expensive but not impossible.
My rescue argument to this is: In this particular case, the size of each slice entry takes 2 machine words (it's a string, consisting of start address and length). Since len(elements) == sizeof(elements) / sizeof(elements) and sizeof(elements) is at least 8, the expression len(elements) cannot overflow. Phew.