jim@jagubox.gsfc.nasa.gov (Jim Jagielski) (01/30/91)
Tell me, is jumping into an IF block statement legal (I know it ain't
pretty)... for example:
program tester
.
.
.
if (value .lt. 0) then
.
.
.
else
22 do something
.
.
end if
.
.
.
if (a.lt.b) goto 22
Is the above legal and acceptable... I can't find any references to it in my
books...
Thanks!
--
=======================================================================
#include <std/disclaimer.h>
=:^)
Jim Jagielski NASA/GSFC, Code 711.1
jim@jagubox.gsfc.nasa.gov Greenbelt, MD 20771
"Exploding is a perfectly normal medical phenomenon. In many fields of
medicine nowadays, a dose of dynamite can do a world of good."gt4512c@prism.gatech.EDU (BRADBERRY,JOHN L) (01/30/91)
In article <2787@dftsrv.gsfc.nasa.gov> jim@jagubox.gsfc.nasa.gov (Jim Jagielski) writes: > >Tell me, is jumping into an IF block statement legal (I know it ain't >pretty)... for example: The program fragment suggested produces the following output (modified and using a Microsoft 5xx Compiler): 15 16 if (value .lt. 0) then 17 COUNT=12345 18 else 19 22 COUNT=0 20 end if 21 22 if (a.lt.b) goto 22 ***** XXX.FTN(22) : warning F4801: label 22 : used across blocks 23 In general, this is NOT considered good programming practice and usually leads to code that is difficult to maintain and modify. To quote Michael Metcalf (c) 1985-88, author of "Effective Fortran 77", Oxford University Press (page 44), "The statements within an IF block may be labelled, but the labels must never be referenced in such a fashion as to pass control into the range of an IF block or ELSE clause ..." When faced with an urge to do something like this, take a deep breath, get a beverage, and RE-THINK your logic. The next person to 'fix' your code will thank you! -- John L. Bradberry |Georgia Tech Research Inst|001100110011001100110011 Scientific Concepts Inc. |Microwaves and Antenna Lab|Int : gt4512c@prism 2359 Windy Hill Rd. 201-J|404 528-5325 (GTRI) |GTRI:jbrad@msd.gatech. Marietta, Ga. 30067 |404 438-4181 (SCI) |'...is this thing on..?'
jim@jagubox.gsfc.nasa.gov (Jim Jagielski) (01/30/91)
In article <20773@hydra.gatech.EDU> gt4512c@prism.gatech.EDU (BRADBERRY,JOHN L) writes: }In article <2787@dftsrv.gsfc.nasa.gov> jim@jagubox.gsfc.nasa.gov (Jim Jagielski) writes: }> }>Tell me, is jumping into an IF block statement legal (I know it ain't }>pretty)... for example: } }In general, this is NOT considered good programming practice and }usually leads to code that is difficult to maintain and modify. } }When faced with an urge to do something like this, take a deep }breath, get a beverage, and RE-THINK your logic. The next person }to 'fix' your code will thank you! } It ain't my code... I've seen this quite a few times on VAX machines (their FORTRAN accepts it without even a hiccup) but, of course, when porting to other machines the code dies a horrible death. Sometimes it does make sense to do this if the block you are referring back to is large... of course, in that case is better to just make it "into" a subroutine and use it as such. In any case, the 3 books I've looked through ("Fortran77" by Meissner/ Organick; "Problem Solving... Fortran 77" by Koffman/Friedman; and "Fortran77 for Engineers..." by Nyhoff/Leestma) don't mention it at all. Oh well... anyway, thanks for all the feedback! -- ======================================================================= #include <std/disclaimer.h> =:^) Jim Jagielski NASA/GSFC, Code 711.1 jim@jagubox.gsfc.nasa.gov Greenbelt, MD 20771 "Exploding is a perfectly normal medical phenomenon. In many fields of medicine nowadays, a dose of dynamite can do a world of good."
gt4512c@prism.gatech.EDU (BRADBERRY,JOHN L) (01/30/91)
In article <2796@dftsrv.gsfc.nasa.gov> jim@jagubox.gsfc.nasa.gov (Jim Jagielski) writes: >In article <20773@hydra.gatech.EDU> gt4512c@prism.gatech.EDU (BRADBERRY,JOHN L) writes: >}In article <2787@dftsrv.gsfc.nasa.gov> jim@jagubox.gsfc.nasa.gov (Jim Jagielski) writes: > >It ain't my code... I've seen this quite a few times on VAX machines (their >FORTRAN accepts it without even a hiccup) but, of course, when porting to >other machines the code dies a horrible death. Sometimes it does make sense >to do this if the block you are referring back to is large... of course, in >that case is better to just make it "into" a subroutine and use it as such. > Sorry about the 'assumption' implied in my response! I have also had the 'pleasure' of converting/fixing/porting VAX Fortran programs with similar constructs. Some compilers are VERY forgiving (stupid) when it comes to the 'semantics' of program statements. Unfortunately, this often causes false assumptions that the code is 'good'. After all, how many times have we heard "...but it works fine, it compiled OK!". Suggesting that it makes sense to violate structured programming techniques in this manner is similar to the arguments for GOTO's,COMEFROM'S,LINE NUMBERS, and other ingredients that frequently result in 'spaghetti code'. I'll admit that I have been guilty of this technique in fits of EXTREME desperation (you know, code you hope NOBODY ever looks at!). However, as one of my programmers used to say, "...there's always time to do it over, but NEVER enough time to do it right in the first place". -- John L. Bradberry |Georgia Tech Research Inst|001100110011001100110011 Scientific Concepts Inc. |Microwaves and Antenna Lab|Int : gt4512c@prism 2359 Windy Hill Rd. 201-J|404 528-5325 (GTRI) |GTRI:jbrad@msd.gatech. Marietta, Ga. 30067 |404 438-4181 (SCI) |'...is this thing on..?'
jim@jagubox.gsfc.nasa.gov (Jim Jagielski) (01/30/91)
In article <20785@hydra.gatech.EDU> gt4512c@prism.gatech.EDU (BRADBERRY,JOHN L) writes: }In article <2796@dftsrv.gsfc.nasa.gov> jim@jagubox.gsfc.nasa.gov (Jim Jagielski) writes: }>In article <20773@hydra.gatech.EDU> gt4512c@prism.gatech.EDU (BRADBERRY,JOHN L) writes: }>}In article <2787@dftsrv.gsfc.nasa.gov> jim@jagubox.gsfc.nasa.gov (Jim Jagielski) writes: }> }>It ain't my code... I've seen this quite a few times on VAX machines (their }>FORTRAN accepts it without even a hiccup) but, of course, when porting to }>other machines the code dies a horrible death. Sometimes it does make sense }>to do this if the block you are referring back to is large... of course, in }>that case is better to just make it "into" a subroutine and use it as such. }> } }Sorry about the 'assumption' implied in my response! Nothing to be sorry 'bout :):) } }Suggesting that it makes sense to violate structured programming techniques }in this manner is similar to the arguments for GOTO's,COMEFROM'S,LINE NUMBERS, }and other ingredients that frequently result in 'spaghetti code'. } I'm not suggesting that it makes sense to violate strucured techniques, I'm only saying that at times I see sense in the reason it's DONE that way... I don't necessarily approve, but I understand why... Of course, I don't think that you were suggesting that I was suggesting... :):):) You recall COMEFROM's too, huh? Anyway, nobody likes GOTO's... until they really NEED one... even C concedes this rather nasty point. Cheers! -- ======================================================================= #include <std/disclaimer.h> =:^) Jim Jagielski NASA/GSFC, Code 711.1 jim@jagubox.gsfc.nasa.gov Greenbelt, MD 20771 "Exploding is a perfectly normal medical phenomenon. In many fields of medicine nowadays, a dose of dynamite can do a world of good."
khb@chiba.Eng.Sun.COM (chiba) (01/31/91)
In article <2787@dftsrv.gsfc.nasa.gov> jim@jagubox.gsfc.nasa.gov (Jim Jagielski) writes:
Tell me, is jumping into an IF block statement legal (I know it ain't
pretty)... for example:
program tester
.
.
.
if (value .lt. 0) then
.
.
.
else
22 do something
.
.
end if
.
.
.
if (a.lt.b) goto 22
Is the above legal and acceptable... I can't find any references to it in my
books...
... discussion of why it's nice to be structured removed...
because
The question was IS IT LEGAL?
The Answer is NO!@!!!!!
Page 11-4 (of X3.9-1978) line 25
Transfer of control into an IF block from outside the IF block
is prohibited.
--
----------------------------------------------------------------
Keith H. Bierman kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33 | (415 336 2648)
Mountain View, CA 94043KENCB@SLACVM.SLAC.STANFORD.EDU (01/31/91)
Jim Jagielski <jim@jagubox.gsfc.nasa.gov> replied: >>In article <20785@hydra.gatech.EDU> gt4512c@prism.gatech.EDU (BRADBERRY,JOHN L) >>writes: >>}In article <2796@dftsrv.gsfc.nasa.gov> jim@jagubox.gsfc.nasa.gov (Jim >>Jagielski) writes: >>}>In article <20773@hydra.gatech.EDU> gt4512c@prism.gatech.EDU (BRADBERRY,JOHN >>L) writes: >>}>}In article <2787@dftsrv.gsfc.nasa.gov> jim@jagubox.gsfc.nasa.gov (Jim >>Jagielski) writes: >>}> >>}>It ain't my code... I've seen this quite a few times on VAX machines (their >>}>FORTRAN accepts it without even a hiccup) but, of course, when porting to >>}>other machines the code dies a horrible death. Sometimes it does make sense >>}>to do this if the block you are referring back to is large... of course, in >>}>that case is better to just make it "into" a subroutine and use it as such. >>}> [stuff deleted] I was very suprised at the VAX Fortran reference because ever since I first read the VAX Fortran manual (VMS V2.1), I "knew" you weren't supposed to jump into a IF-block. Quoting from the current maunal (VMS V5.x, VAX Fortran V5.x) description of Block IF Statements (Sect. 5.7.3), p 5-21: "5.7.3.1 Statement Blocks A statement block can contain any executable FORTRAN statement except an END statement. You can transfer control out of a statement block, but you must not transfer control into a block. Thus, you must not transfer control from one statement block to another." The second sentence is the relavent one. However, MUCH to my SURPRISE, John's test program fragment compiled just FINE under VAX Fortran! Sheez! I think it's time for an SPR on this... but then I don't know the history (PDP-11 compatibility, etc.). -Ken +---------------------------------------------------------------------------+ | Kenneth H. Fairfield | Internet: Fairfield@Tpc.Slac.Stanford.Edu | | SLAC | DECnet: 45047::FAIRFIELD | | P.O.Box 4349, Bin 98 | BITNET Fairfield@SlacTpc | | Stanford, CA 94309 | Phone: (415) 926-2924 | +---------------------------------------------------------------------------+ "These opinions are worth what you paid for 'em... ...and are they mine, not SLAC's, Stanford's, nor the DOE's..."
khb@chiba.Eng.Sun.COM (chiba) (01/31/91)
In article <91030.132436KENCB@SLACVM.SLAC.STANFORD.EDU> KENCB@SLACVM.SLAC.STANFORD.EDU writes:
...
but you must not transfer control into a block. Thus, you must not
transfer control from one statement block to another."
The second sentence is the relavent one.
However, MUCH to my SURPRISE, John's test program fragment compiled just
FINE under VAX Fortran! Sheez! I think it's time for an SPR on this...
but then I don't know the history (PDP-11 compatibility, etc.).
In general, a FORTRAN processor (x3.9-1978 compliant), may do anything
it wants to with a non-standard compliant program. Similarly with
vendor documents, the constraint is on the user to not write illegal
(viz. code which violates the vendor's document) code. If you do, it
MAY work. That isn't a bug.
--
----------------------------------------------------------------
Keith H. Bierman kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33 | (415 336 2648)
Mountain View, CA 94043whit@milton.u.washington.edu (John Whitmore) (01/31/91)
In article <91030.132436KENCB@SLACVM.SLAC.STANFORD.EDU> KENCB@SLACVM.SLAC.STANFORD.EDU writes: > [stuff deleted] > >I was very suprised at the VAX Fortran reference because ever since I first >read the VAX Fortran manual (VMS V2.1), I "knew" you weren't supposed to >jump into a IF-block. >However, MUCH to my SURPRISE, John's test program fragment compiled just >FINE under VAX Fortran! Sheez! I think it's time for an SPR on this... I second the motion; an SPR would indeed be appropriate. I try to keep my VMS FORTRAN code compliant (using FORTRAN/STANDARD is a big help). This is the second nonstandard extension I've seen unflagged (the first is the free-format use of TAB character). Not flagging the TAB use is reasonable (it's easy to edit out, and the number of violations in a long program can be staggering). The IF block entry is not easy to edit out, but would require some rethinking if porting to a new compiler were attempted. John Whitmore
khb@chiba.Eng.Sun.COM (chiba) (01/31/91)
In article <15512@milton.u.washington.edu> whit@milton.u.washington.edu (John Whitmore) writes:
try to keep my VMS FORTRAN code compliant (using FORTRAN/STANDARD is
... Not flagging the TAB use is reasonable (it's easy to edit out, and
the number of violations in a long program can be staggering). The
IF block entry is not easy to edit out, but would require some
rethinking if porting to a new compiler were attempted.
The "right" approach is to have a good standards checker. Such are
available from several sources. This issue of Fortran Users Journal
has a writeup on FORWARN.
some names/address
Fortran lint IPT 1096 East Meadow Circle, Palo Alto, CA 94303,
415-494-7500. 14 day free demos. Very useful, ANSI compliance, VAX
extensions, etc.
FORWARN Quibus Enterprises: 217 356 8876
available. Not as good, IMHO. Cheaper
Flint(tm) Programming Research ltd:
FAX (44) 01 336 1151 voice
(44) 1 942 9242
Also
8701 Bedford Euless Rd.
Suite 520
Hurst TX 76053 USA
ph: 817-589-0949, fax: 817-595-4611
FORCHECK Leiden University Box 9604
2300 RC Leiden
The Netherlands
31-71-276804
Related tools of interest:
FOR_STRUCT Cobolt-Blue 2940 Union Ave Suite C San Jose CA 95124
408 723 0474. This is a "reverse engineering tool" to
use the COBOL lingo, viz. makes old code more readable
and maintainable. I have not used it myself.
SPAG Similar to for_struct. Not a very unixlike interface,
but otherwise quite good.
US distributor: OTG
voice 717 222 9100
fax 717 229 9103
Authors:
Polyhedron Software Ltd
Magdalen House
98 Abingdon Road
Standlake
Witney
Oxon OX8 7RN
Tel 0865 300 579
--
----------------------------------------------------------------
Keith H. Bierman kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33 | (415 336 2648)
Mountain View, CA 94043u502sou@mpirbn.mpifr-bonn.mpg.de (Ignatios Souvatzis) (01/31/91)
In article <KHB.91Jan30160426@chiba.Eng.Sun.COM> khb@chiba.Eng.Sun.COM (chiba) writes: In general, a FORTRAN processor (x3.9-1978 compliant), may do anything it wants to with a non-standard compliant program. Similarly with vendor documents, the constraint is on the user to not write illegal (viz. code which violates the vendor's document) code. If you do, it MAY work. That isn't a bug. That's the BAD think about FORTRAN... most dangerous things are 'forbidden' by the manuals, but most of them pass the compiler... It's much fun to debug a program where you forgot a subroutine parameter... -- Paper mail: Ignatios Souvatzis, Radioastronomisches Institut der Universitaet Bonn, Auf dem Huegel 71, D-5300 Bonn 1, FRG Internet: u502sou@mpirbn.mpifr-bonn.mpg.de
fisher@qut.edu.au (01/31/91)
In article <2787@dftsrv.gsfc.nasa.gov>, jim@jagubox.gsfc.nasa.gov (Jim Jagielski) writes: > > Tell me, is jumping into an IF block statement legal (I know it ain't > pretty)... for example: > . > . > Is the above legal and acceptable... I can't find any references to it in my > books... > I assume we are talking about FORTRAN 77. COMMENCE HOBBY HORSE As recently discussed there is only one authoritative book and it should be consulted by anyone answering this sort of question. It is ANSI X3.9-1978 and is easily obtained from the American National Standards Institute or your national Standards Organisation. END HOBBY HORSE 11.6.2 defines an IF-Block 11.6.3 paragraph 2 says "Transfer of control into an IF-block from outside the IF-block is prohibited." 11.7 and 11.8 include equivalent statements for ELSE IF-blocks and ELSE blocks. I cannot talk for the writers of ANSI X3.9-1978 but it is not hard to imagine that this prohibition simplifies the task of the writers of optimising compiler writers. Bill
jim@jagubox.gsfc.nasa.gov (Jim Jagielski) (02/01/91)
In article <U502SOU.91Jan31110246@mpirbn.mpifr-bonn.mpg.de> u502sou@c1a writes: }In article <KHB.91Jan30160426@chiba.Eng.Sun.COM> khb@chiba.Eng.Sun.COM }(chiba) writes: } } } In general, a FORTRAN processor (x3.9-1978 compliant), may do } anything it wants to with a non-standard compliant program. } Similarly with vendor documents, the constraint is on the user to } not write illegal (viz. code which violates the vendor's document) } code. If you do, it MAY work. That isn't a bug. } }That's the BAD think about FORTRAN... most dangerous things are }'forbidden' by the manuals, but most of them pass the compiler... It's }much fun to debug a program where you forgot a subroutine parameter... } Yeah, it would be nice if either the compiler complained (some do, some don't... I like the ones that do) or else there was lint for Fortran... Note: I didn't say anything about the standard requiring compilers to complain, did I? -- ======================================================================= #include <std/disclaimer.h> =:^) Jim Jagielski NASA/GSFC, Code 711.1 jim@jagubox.gsfc.nasa.gov Greenbelt, MD 20771 "Exploding is a perfectly normal medical phenomenon. In many fields of medicine nowadays, a dose of dynamite can do a world of good."
jlg@lanl.gov (Jim Giles) (02/02/91)
From article <U502SOU.91Jan31110246@mpirbn.mpifr-bonn.mpg.de>, by u502sou@mpirbn.mpifr-bonn.mpg.de (Ignatios Souvatzis): > [...] > That's the BAD think about FORTRAN... most dangerous things are > 'forbidden' by the manuals, but most of them pass the compiler... It's > much fun to debug a program where you forgot a subroutine parameter... It's not Fortran! ALL ANSI defined languages allow implementation extensions. ALL of them leave the interpretation of non-conforming programs up to the discretion of the impementation. Actually, C is one of the worst offenders in this area. J. Giles
preston@LL.MIT.EDU (Steven Preston) (02/04/91)
In article <91030.132436KENCB@SLACVM.SLAC.STANFORD.EDU> KENCB@SLACVM.SLAC.STANFORD.EDU writes: > However, MUCH to my SURPRISE, John's test program fragment compiled just > FINE under VAX Fortran! Sheez! This is unfair to VAX Fortran. If you would do a "help fortran" you might notice that there is are /standard and /f77 switches. The /standard switch, along with the /warnings switch, will produce warning messages when certain vax extensions to the standard. In particular, it generated this for me: %FORT-I-EXTILBRNCH, Extension to FORTRAN-77: Nonstandard branch into block This seems to be very reasonable, to provide an extension (which is legal under the standard) and a way to warn when it is used. -- Steve Preston
maine@elxsi.dfrf.nasa.gov (Richard Maine) (02/05/91)
On 4 Feb 91 15:20:45 GMT, preston@LL.MIT.EDU (Steven Preston) said: Steven> In article <91030.132436KENCB@SLACVM.SLAC.STANFORD.EDU> KENCB@SLACVM.SLAC.STANFORD.EDU writes: > However, MUCH to my SURPRISE, John's test program fragment compiled just > FINE under VAX Fortran! Sheez! Steven> This is unfair to VAX Fortran. If you would do a "help fortran" you Steven> might notice that there is are /standard and /f77 switches. The Steven> /standard switch, along with the /warnings switch, will produce Steven> warning messages when certain vax extensions to the standard. Steven> ... Steven> This seems to be very reasonable, to provide an extension (which is Steven> legal under the standard) and a way to warn when it is used. Agreed. However, I'd quarrel with the system's choice of default switches. This is a fairly generic issue, not just a Vax complaint, or I wouldn't have bothered to post. I actually don't use Vaxen much at the moment, but I've raised simillar questions with other vendors. Although extensions are fine in general, I prefer to see at least the "unsafe" extensions disabled by default. The term "unsafe" is admitedly vague here. I think of an unsafe extension as one that might provide a cover for programming errors to pass undetected. For a trivial (and common) example, allowing string = 'a' where "string" is (implicitly) real counts as an unsafe extension in my book. The odds are just to strong that the programmer forgot to declare string as character instead of intending to use the extension. On the other hand, allowing mixed case or long variable names seems innocuous; it is unlikely to misinterpret the programmer's intent. (Unless the programmer comes from a C background and thinks it reasonable that N and n be the names of 2 different varables). The problem with allowing extensions (particularly "unsafe" ones) by default is that this means the most inexperienced programmers will invariably be compiling with the extensions enabled. These are the programmers most in need of the help that /standard or /warning switches or their equivalents provide. (I don't mean for a second to imply that experienced programmers can't also use the help, just that the inexperienced ones need it more). The programmer wanting to use special extensions should at least be aware that they are extensions and it seems reasonable to ask him or her to set the switch enabling them. I have a simillar position about defaults optimization and debug switches. I think default switch settings should be conservative to help catch problems and that people trying to tune codes for maximum performance should be expected to be more aware of switch options than people that are occasional programmers just trying to get something to work.
KENCB@SLACVM.SLAC.STANFORD.EDU (02/05/91)
In article <9102041020.AA00951@LL.MIT.EDU>, preston@LL.MIT.EDU (Steven Preston) says: > >In article <91030.132436KENCB@SLACVM.SLAC.STANFORD.EDU> >KENCB@SLACVM.SLAC.STANFORD.EDU writes: >> However, MUCH to my SURPRISE, John's test program fragment compiled just >> FINE under VAX Fortran! Sheez! > >This is unfair to VAX Fortran. If you would do a "help fortran" you >might notice that there is are /standard and /f77 switches. The [stuff deleted] >Steve Preston No. That's *not* the point. (In fact I love the VAX Fortran extensions, if the truth be known...) The point is that the *documentation* states that the jump into an IF-block is ILLEGAL, *not* that it is allowed as a VAX extension. Most (all?) VAX extensions are clearly labeled as such by the different colored ink used in the manual, etc. Can you point me to a place in the manual (or help file) that states that jumps into an IF-block are an allowed VAX extension to the standard?? -Ken +---------------------------------------------------------------------------+ | Kenneth H. Fairfield | Internet: Fairfield@Tpc.Slac.Stanford.Edu | | SLAC | DECnet: 45047::FAIRFIELD | | P.O.Box 4349, Bin 98 | BITNET Fairfield@SlacTpc | | Stanford, CA 94309 | Phone: (415) 926-2924 | +---------------------------------------------------------------------------+ "These opinions are worth what you paid for 'em... ...and are they mine, not SLAC's, Stanford's, nor the DOE's..."
joevl@mojsys.com (Joe Vlietstra) (03/05/91)
In article <2787@dftsrv.gsfc.nasa.gov> jim@jagubox.gsfc.nasa.gov (Jim Jagielski) writes: >[ommitted stuff] > . > if (value .lt. 0) then > . > else >22 do something > . > end if > . > if (a.lt.b) goto 22 > >Is the above legal and acceptable... I can't find any references to it in my >books... I can't find my copy of the FStandard, so I can't cite the exact paragraph. But jumps into the body of a block IF are definitely NOT allowed in F77 and I believe they are not allowed in F90. (I only have a draft of F90 -- back when F8X was a possibility :-) VAX FORTRAN allows these jumps and many compilers provide VAX compatibility options to allow these jumps -- but I recommend rewritting the routine. Joe Vlietstra -- ------------------------------------------------------------------ Joe Vlietstra | Checked Daily: ...!uunet!mojsys!joevl Mojave Systems Corp | Checked Weekly: mojave@hmcvax.claremont.edu 1254 Harvard Avenue | Iffy Routing: joevl@mojsys.com
mlubran@csws5.ic.sunysb.edu (Michael J Lubrano) (03/06/91)
>In article <2787@dftsrv.gsfc.nasa.gov> jim@jagubox.gsfc.nasa.gov (Jim Jagielski) writes: >>[ommitted stuff] >> . >> if (value .lt. 0) then >> . >> else >>22 do something >> . >> end if >> . >> if (a.lt.b) goto 22 >> >>Is the above legal and acceptable... I can't find any references to it in my >>books... > A much better way to write this would be: 10 IF (VAL.LT.0)THEN . ELSE C DO SOMETHING . END IF . C FORCE PROGRAM FLOW IF(A.LT.B)THEN VAL=100 GO TO 10 END IF setting VAL greater than 0 forces the conditional (VAL.LT.0) to defualt to the else, which is exactly where you want to be. Q.E.D Mike Lubrano
schmidtg@iccgcc.decnet.ab.com (03/13/91)
In article <1991Mar6.154720.1162@sbcs.sunysb.edu>, mlubran@csws5.ic.sunysb.edu (Michael J Lubrano) writes: >>In article <2787@dftsrv.gsfc.nasa.gov> jim@jagubox.gsfc.nasa.gov (Jim Jagielski) writes: >>>[ommitted stuff] >>> . >>> if (value .lt. 0) then >>> . >>> else >>>22 do something >>> . >>> end if >>> . >>> if (a.lt.b) goto 22 >>> >>>Is the above legal and acceptable... I can't find any references to it in my >>>books... >> > > A much better way to write this would be: > > 10 IF (VAL.LT.0)THEN > . > ELSE > C DO SOMETHING > . > END IF > . > C FORCE PROGRAM FLOW > IF(A.LT.B)THEN > VAL=100 > GO TO 10 > END IF > > setting VAL greater than 0 forces the conditional (VAL.LT.0) > to defualt to the else, which is exactly where you want to be. > > Q.E.D > > > Mike Lubrano Hmmm... looks like an infinite loop to me unless "do something" has an additional side effect of forcing (a .ge. b)!!! In general, you don't want to change control flow in your program by forcing variables to assume bogus values. Too many side effects, and what if you want to reuse that variable later on? Here is how I would approach the problem. . if (value .lt. 0) then . limit = 0 else limit = 1 end if if (a .lt. b) limit = limit + 1 end if do 22 i = 1,limit do something 22 continue -or- better still... . if (value .lt. 0) then . else call do_something() . end if . if (a .lt. b) then call do_something() end if -- ============================================================================= Greg Schmidt -> schmidtg@iccgcc.decnet.ab.com ============================================================================= "People with nothing to hide have nothing to fear from O.B.I.T" -- Peter Lomax ----------------------------------------------------------------------------- Disclaimer: No warranty is expressed or implied. Void where prohibited. =============================================================================