home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!noc.near.net!hri.com!spool.mu.edu!howland.reston.ans.net!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!mccall!mccall!tp
- From: tp@mccall.com (Terry Poot)
- Newsgroups: comp.os.vms
- Subject: Re: Recursion in FORTRAN
- Message-ID: <1993Jan21.092628@mccall.com>
- Date: 21 Jan 93 15:26:28 GMT
- References: <1jj8enINNqik@gap.caltech.edu> <1993Jan20.180757.2587@pony.Ingres.COM> <1993Jan20.195642.13310@dbased.nuo.dec.com>
- Reply-To: tp@mccall.com (Terry Poot)
- Organization: The McCall Pattern Co., Manhattan, KS, USA
- Lines: 23
- Nntp-Posting-Host: mis1
- Nntp-Posting-User: tp
-
-
- In article <1993Jan20.195642.13310@dbased.nuo.dec.com>,
- lionel@quark.enet.dec.com (Steve Lionel) writes:
- >As of DEC Fortran V6.0 on OpenVMS (currently shipping on Alpha AXP systems,
- >soon to come on VAX), SAVE will NOT be a no-op. So be sure to use it if you
- >want the value saved upon exit from the routine. Note that SAVE does not
- >necessarily mean "static allocation"; there is a STATIC statement for that.
- >(In practical terms, SAVE does cause static allocation, but you should say
- >what you mean and mean what you say.)
-
- I want to be real clear about this (I hear the sound of 200,000 lines of legacy
- fortran code shattering to little bits). As of v6.0, values not explicitly
- mentioned in a SAVE statement can not be guaranteed to survive from call to
- call, right? Any qualifiers to preserve the current behavior?
-
- Of course, *I* don't write code this way, but I didn't write most of the stuff I
- support, and I haven't attempted to go into all our code and find where it needs
- SAVE statements (it needs lots of them). (Time to read up on SCA's inspect
- command, I guess.)
- --
- Terry Poot <tp@mccall.com> The McCall Pattern Company
- (uucp: ...!rutgers!depot!mccall!tp) 615 McCall Road
- (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA
-