Range based for loops and integer overflow

[zagortenay333]

While making range based loops for my own compiler I noticed an awkward case. The following loop will run forever in odin:

package main

main :: proc() {
    x : u8 = 0;
    y : u8 = 255;
    for i in x..y { }
}

It's because the loop terminates when x is strictly larger than y, but that's not possible here.

Is this intended behavior? I'll probably leave it like this in my own toy compiler since it's easier to handle.

EDIT

I opened an issue for this: #990

[ThisDevDane]

@gingerBill Huh, that doesn't seem intended at all? It indeed just spins around and around.

[gingerBill]

This was intended behaviour but I have now made Odin follow this more "intuitive" behaviour by adding an explicit check to these kinds of for loops, meaning an extra branch may be required (assuming it does not get optimized out).

[Kelimion]

Seems to me that it's treated as <256, so it'll overflow to zero. 0..0, infinite loop.

[zagortenay333]

It's not 0..0. What happens is: 0..255 -> 254..255 -> 255..255 -> 0..255 -> ....

[krixano]

Ooooh, that's a good point! I think Kelimion you're saying that the compiler is using <256 instead of <= 255?
This bug is pretty weird, lol.

[Kelimion]

Ooooh, that's a good point! I think Kelimion you're saying that the compiler is using <256 instead of <= 255?
This bug is pretty weird, lol.

That was my guess at the time based on the wrapping behavior. It's since been investigated more deeply.

[gingerBill]

I have implemented the more "intuitive" behaviour now into the Odin compiler: #990

Previously, for i in x .. y {} was implemented like this:

for i := x; i <= y; i += 1 {}

Which will cause an infinite loop if y is equal to the maximum value of that integer type.

The new behaviour acts like this:

for i := x; i <= y; /**/ {
    // body
   if i == y {
       break;
   }
   i += 1;
}

If y is known at compile time by the backend, then that branch can be removed. However if y is not know at compile time (especially if y is a procedure call or something), then that branch must exist.

[gingerBill]

It should also be noted that internal integer promotion may not be relied upon, especially if the integer is the maximum integer type already.

[gingerBill]

for i in x ..< y {} does not need any special treatment

[zagortenay333]

@gingerBill The loop you show above does not match what I suggested. My implementation only performs one check per iteration, yours does two: i<=y and i==y.
In my implementation you jump unconditionally to the start of the loop body after i==y fails.

[zagortenay333]

To be precise, it performs two checks for the first iteration, and only 1 check for the subsequent iterations.