🚀 go-pugleaf

In 5099@aw.sei.cmu.edu, firth@sei.cmu.edu (Robert Firth) quotes an earlier
article about the semantics of FOR loops and says:

>... thereby perpetuates the design or implementation error that
>has cursed FOR-loops since the days of Algol-60: a loop set to end on the
>largest value of the associated type will fail.
>
>This is 1988.  Let's at least put THAT right!

This is purely an implementation issue.  MacMETH does it correctly, as
I'm sure some other compilers do.  At the bottom of the loop, MacMETH
generates an ADDI or SUBI, followed by either a BVC (INTEGER or LONGINT)
or a BCC back to the top of the loop.  Note that this correctly handles
    FOR u := 0 TO MAX(CARDINAL) BY 2 DO ... END;
Stopping on >= before the increment, rather than > after the increment,
would not help in this case, although I suppose the generated code could
decrement the limit by (stepsize-1) before the loop, and then use a >=
test before increment.

If your compiler doesn't handle these limit situations correctly, gripe
at the vendor until they fix it.  (Hi, Eli! :-))

Of course this means that a FOR loop is not EXACTLY equivalent to the
corresponding WHILE, since the WHILE version will either ignore the
carry/overflow or abort execution, depending on the implementation.

Christopher Jewell                |  If God had meant for us to fly, He
chrisj@cup.portal.com             |  would NEVER have given us the railways.
ucbvax!sun!cup.portal.com!chrisj  |                     -- Flanders & Swan