"Andreas Raab" <Andreas.Raab at gmx.de> wrote:
	We fixed this problem today. It turned out that there was a slight
	mismatch in boundary conditions with #to:do: loops - Squeak evaluates
	the upper bound only once whereas the equivalent C code (using for(;;))
	may do this multiple times.

Er, I ran into a problem that was caused by Squeak doing the C thing here.
I _wrote_
    1 to: n do: [: i | ... ]
and got the same effect, in fact the same bytecodes, as for
    i := 1.
    [i <= n] whileTrue: [... i := i + 1].
or something like that.  I was annoyed, because n was changing, and I had
written it as a method call precisely so it _would_ be evaluated once.

Here's an example I just tried in Squeak 3.2:

    n := 1.
    r := OrderedCollection new.
    1 to: n do: [:i | r add: i. n _ n - 1].
    r

select the lot in a workspace, and PrintIt.

==> an OreredCollection(1 2 3 4 5).

This does not look like #to:do: evaluating its upper bound just once...