Re: FOR loop limit -- RPG400-L

Mark,

Are you suggesting that the compiler should be able to follow program logic to determine what the value of the limit is prior to the for loop? That value could have been set anywhere in the program before the loop was hit. Yes, in the simple example it was the statement before, but...

Maybe I missed your point :-)

----- Original Message ----- From: "Mark S. Waterbury" <mark.s.waterbury@xxxxxxx>
To: "RPG programming on the IBM i / System i" <rpg400-l@xxxxxxxxxxxx>
Sent: Thursday, January 29, 2009 3:19 PM
Subject: Re: FOR loop limit

Hi, Rory:

Thanks for that link and the doc. excerpt -- I still think this is a
compiler error. The compiler should emit a compile time error,
indicating that the size of the variable is not sufficient, based on the
fact that the compiler "knows" at compile-time the upper limit, in this
case, since it was coded as a literal.

On the other hand, if you had coded:

FOR i = 1 TO x BY 1

then the compiler does not "know" what the upper limit value will be,
but some deductions can be made, e.g. based on the size of the variable
X, especially if both "i" and "x" are declared to be packed decimal.

I still think if the increment is 1, the generated code should never
cause this exception. At least, that's the semantics in most other HLLs
that I know that have a similar for-loop construct. Or, they specify
that the value of the index variable is "undefined" upon exit from the
loop. Oh, well...

Cheers,

Mark S. Waterbury

> Rory Hewitt wrote:

Not a compiler error:
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/books/c092508502.htm

The FOR operation is performed as follows:

1. If the conditioning indicators on the FOR statement line are
satisfied, the FOR operation is processed (step 2). If the indicators are
not satisfied, control passes to the next operation to be processed
following the associated END or ENDFOR statement (step 8).
2. If specified, the initial value is assigned to the index name.
Otherwise, the index name retains the same value it had before the start of
the loop.
3. If specified, the limit value is evaluated and compared to the index
name. If no limit value is specified, the loop repeats indefinitely until it
encounters a statement that exits the loop (such as a LEAVE or GOTO) or that
ends the program or procedure (such as a RETURN).

If the TO clause is specified and the index name value is greater than
the limit value, control passes to the first statement following the ENDFOR
statement. If DOWNTO is specified and the index name is less than the limit
value, control passes to the first statement after the ENDFOR.
4. The operations in the FOR group are processed.
5. If the conditioning indicators on the END or ENDFOR statement are not
satisfied, control passes to the statement after the associated END or
ENDFOR and the loop ends.
6. If the increment value is specified, it is evaluated. Otherwise, it
defaults to 1.
7. The increment value is either added to (for TO) or subtracted from
(for DOWNTO) the index name. Control passes to step 3. (Note that the
conditioning indicators on the FOR statement are not tested again (step 1)
when control passes to step 3.)
8. The statement after the END or ENDFOR statement is processed when the
conditioning indicators on the FOR, END, or ENDFOR statements are not
satisfied (step 1 or 5), or when the index value is greater than (for TO) or
less than (for DOWNTO) the limit value (step 3), or when the index value
overflows.

"If the FOR loop is performed *n* times, the limit value is evaluated
*n+1*times and the increment value is evaluated
*n* times. This can be important if the limit value or increment value is
complex and time-consuming to evaluate, or if the limit value or increment
value contains calls to subprocedures with side-effects. If multiple
evaluation of the limit or increment is not desired, calculate the values in
temporaries before the FOR loop and use the temporaries in the FOR loop."

On Thu, Jan 29, 2009 at 9:43 AM, Mark S. Waterbury <mark.s.waterbury@xxxxxxx

wrote:

Hi, Jeff:

IMHO, that looks like an error ("bug") in the compiler generated code --
you should open a PMR with IBM.

What VxRyMz of i5/OS or OS/400 did you encounter this problem at? And
what did you specify for TGTRLS? (That could affect it if this problem
was already fixed in a subsequent release).

Mark S. Waterbury

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.