Path: utzoo!mnetor!uunet!husc6!cmcl2!beta!unm-la!unmvax!nmtsun!hydrovax
From: hydrovax@nmtsun.nmt.edu (M. Warner Losh)
Newsgroups: comp.lang.fortran
Subject: Re: Modifying iteration variables in DO loops
Message-ID: <1340@nmtsun.nmt.edu>
Date: 3 Feb 88 20:55:46 GMT
References: <1309@nmtsun.nmt.edu> <4026@aw.sei.cmu.edu> <1331@nmtsun.nmt.edu>
Organization: NMT Hydrology program
Lines: 56
Keywords: X3 standard FORTRAN 77
Summary: This doesn't either, for the same reason

In article <1331@nmtsun.nmt.edu>, john@nmtsun.nmt.edu (John Shipman) writes:
> Apologies for my erroneous earlier posting.  I have this problem
> trying to stay awake while reading X3 standards.

After reading through them myself, I recommend them to all those suffering
from insomnia.

> 
> Next question: what if you pass the iteration variable to a subroutine
> and that subroutine clobbers it?  It would be hard for the compiler
> to know that, especially if the subroutine were linked in later.
> 
> [Example deleted]
>
> Does this program conform to the standard?  If not, is there any
> reasonable way for the compiler to catch the violation?

No, this doesn't, as it redefines the loop variable in devious and
subtle ways.

The compiler on VMS (at least DEC's compiler) for FORTRAN-77 flags
this error as a "possible" loop variable modification, even when the
program units are in two different files and compiled at different
times.  Other than this rather trivial check (if this variable is a
loop counter of an active DO-LOOP and it is passed to a subprogram,
then print this warning message), I think that a compiler would have a
hard time finding stuff like this, especially if the program were a
thousand times more complex.  Even if the compiler had all of the
routines to play with (which it isn't supposed to do, since each
program unit is supposed to be a separate unit), I maintain that the
compiler couldn't get this stuff correct in all cases.  Global data
flow analysis is inherently difficult.

There was a point made in this news group a while ago about what standard
conforming compilers had to do.  The consensus was that they need only
interpret correct programs correctly.  With all other programs, all
bets are off, or so the reasoning went.

Good point John, about this topic.  I have had to work with old FORTRAN-IV
programs that do these dastardly things.  When the original author wanted
to end a do loop, he didn't jump to a label outside of the range of the
do-loop, he assigned the upper bounds to the loop variable, and let
the program exit the loop AS IF IT HAD BEEN done normally.  When I got
the program, I was told to make it work.  Yeh.  Right.  Fortunately, all
I needed to do was compile it...and it "appeared" to work.

I wonder how many people have spent hours trying to debug a program that
accidentally modified a loop variable .....



-- 
bitnet:	losh@nmt.csnet			M. Warner Losh
	warner@hydrovax.nmt.csnet    ! Don't know if this works, let me know.
csnet:	warner@hydrovax.nmt.edu
uucp:	...{cmcl2, ihnp4}!lanl!unmvax!nmtsun!warner%hydrovax