Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!eecae!tank!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.fortran
Subject: Re: FORTRAN porting question
Message-ID: <16715@mimsy.UUCP>
Date: 4 Apr 89 05:08:52 GMT
References: <1868@quanta.eng.ohio-state.edu> <11447@lanl.gov>
Distribution: usa
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 41

In article <11447@lanl.gov> jlg@lanl.gov (Jim Giles) suggests two
alternatives to
>> 	IF (I.EQ.J) GOTO 1000
>> 	...
>> 	DO 1000 K=1,77
>> 	...
>>    1000 CONTINUE

the first being to go around the loop (I give about a 20% chance
to this being what the original coder---that is, the one who put
in the goto---intended), the second being

>C     NOTE: THIS ONE MAY FAIL DUE TO K BEING UNDEFINED AT THIS POINT.
>      IF (I.EQ.J) GOTO 1000
>      ...
>      K=0
>  999 K=K+1
>      ...
> 1000 IF (K.LT.77) goto 999

(minor bug: should be k .le. 77); I give this one a 30% chance of
being what the original coder intended.  But there is a third
alternative:

	if (i .eq. j) goto 999
	...
	k = 1
    998 ...
    999 k = k + 1
   1000 if (k .le. 77) goto 998

I give this one a 30% chance of being what the original coder
intended.

If you add up these chances, you will see a `missing' 20%.

I give that to the possibility that the original coder did not
mean any of these after all: that the original `if i==j' is a bug.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris