It is doing exactly what you say - the code as generated simply lets the "overflow" occur, which is what makes it fast. In particular, if the index variable ove

It is doing exactly what you say - the code as generated simply lets the "overflow" occur, which is what makes it fast. In particular, if the index variable overflows the size of `int` it will just keep increasing. Effectively, the compiler has replaced int with long under the covers, since the cases where the behavior between int and long differ are exactly the cases where the int has overflowed. So it's not always the case that the compiler assumes "overflow won't happen" and then _removes code_ - it just compiles code in a way that is ideal for the non overflow case and then what happens in the overflow case just falls out of the generated assembly (usually it does something bad like OOB access, but the same would generally be true of a wrapping overflow also). You can't make this "implementation defined though", because the behavior is from a C-source point of view, it is effectively: "In the case an int overflows, we silently add 32 more bits and keep incrementing". Obviously you can't support that behavior in general, and even in specific cases it leads to nonsense like ints have non-representable values, etc.