On Saturday, 22 February 2020 11:54:43 UTC, Nigel Tao wrote: > > > If the step (e.g. 3) does not divide the length evenly, then e.g. "i > += 3" can overflow such that i becomes negative, even though the > "len(a)" in the "i < len(a)" condition is a legitimate array or slice > length: a non-negative int, less than or equal to INT_MAX. > > See: > https://play.golang.org/p/QGNKOtw3m62 > > That's an interesting thought. I note that in the original code, the array is being indexed by an int. If the platform is one where int is 64 bits, the problem is moot as no existing hardware could handle an array with 2^63 elements.
My guess is it's do do with the boundary conditions for which the optimisation is written. For a loop with step N which divides into the array size, the compiler knows that all of a[i] to a[i + N-1] are safe, i.e. the slice a[i:i+N] is safe, inside the loop. However this is not true if N doesn't divide into the array size, as the final iteration has a smaller range of safe offsets. It probably wasn't worth calculating the smaller safe range, as it's unlikely to benefit any real-world program. It *could* have said that in that circumstance, only a[i] is safe - but again, probably doesn't benefit many real-world programs. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/ff7c77d8-ac1a-4be1-8301-68bd22c27de9%40googlegroups.com.
