For Loop Bug

[Aldrin-John-Olaer-Manalansan]

For Loop always guarantees one iteration when passing variables as its parameters

2@ = 0
for 0@ = 1 to 2@ // the same as: for 0@ = 1 to 0
	0AD1: show_formatted_text_highpriority "%d %d" time 2000 0@ 2@
end

1@ = 1
2@ = 0
for 0@ = 1@ to 2@ // the same as: for 0@ = 1 to 0
	0AD1: show_formatted_text_highpriority "%d %d" time 2000 0@ 2@
end

The For loop should not continue executing inside if its two parameters were out of bounds.

[Aldrin-John-Olaer-Manalansan]

This is my workaround to fix this problem. I do hope for this to be implemented in the future.

For Loop(Incrementing)

• High Level Normal Syntax:

For 0@ = 1@ to 2@ step 3@
    // ~~~~~~~~~~~~~~~~~~do something inside the for loop~~~~~~~~~~~~~~~~~~
end

• High Level Counter Part:

0085: 0@ = 1@
while 002D: 2@ >= 0@
    // ~~~~~~~~~~~~~~~~~~do something inside the for loop~~~~~~~~~~~~~~~~~~
    005A: 0@ += 3@
end

• Low Level Counter Part:

0085: 0@ = 1@ // (int)
:IterateForLoop
002D:   2@ >= 0@ // (int)
004D: jump_if_false @BreakForLoop
// ~~~~~~~~~~~~~~~~~~do something inside the for loop~~~~~~~~~~~~~~~~~~
005A: 0@ += 3@ // (int)
0002: jump @IterateForLoop
:BreakForLoop

For Loop(Decrementing)

• High Level Normal Syntax:

For 0@ = 1@ downto 2@ step 3@
    // ~~~~~~~~~~~~~~~~~~do something inside the for loop~~~~~~~~~~~~~~~~~~
end

• High Level Counter Part:

0085: 0@ = 1@ // (int)
while 002D: 0@ >= 2@ // (int)
    // ~~~~~~~~~~~~~~~~~~do something inside the for loop~~~~~~~~~~~~~~~~~~
    0062: 0@ -= 3@ // (int)
end

• Low Level Counter Part:

0085: 0@ = 1@ // (int)
:IterateForLoop
002D: 0@ >= 2@ // (int)
004D: jump_if_false @BreakForLoop
// ~~~~~~~~~~~~~~~~~~do something inside the for loop~~~~~~~~~~~~~~~~~~
0062: 0@ -= 3@ // (int)
0002: jump @IterateForLoop
:BreakForLoop

[x87]

thanks for reporting and a workaround. I think it makes sense !

[x87]

as of 3.8.1 compiler adds extra condition before the loop body to ensure the mix and max values for the counter are valid, otherwise skips the loop. this potentially is a breaking change if script relied on this undefined behavior, but I anticipate the impact to be minimal.

[x87]

fixed in 3.8.1