home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / vms / 21735 < prev    next >
Encoding:
Internet Message Format  |  1993-01-22  |  2.2 KB
  1. Path: sparky!uunet!cs.utexas.edu!sdd.hp.com!ux1.cso.uiuc.edu!moe.ksu.ksu.edu!mccall!mccall!tp
  2. Newsgroups: comp.os.vms
  3. Subject: Re: Recursion in FORTRAN
  4. Message-ID: <1993Jan22.085253@mccall.com>
  5. From: tp@mccall.com (Terry Poot)
  6. Date: Fri, 22 Jan 1993 08:52:52 CST
  7. Reply-To: tp@mccall.com (Terry Poot)
  8. References: <1jj8enINNqik@gap.caltech.edu> <1993Jan20.180757.2587@pony.Ingres.COM>  <1993Jan21.195804.6787@dbased.nuo.dec.com>
  9. Organization: The McCall Pattern Co., Manhattan, KS, USA
  10. Nntp-Posting-Host: mis1
  11. Nntp-Posting-User: tp
  12. Lines: 36
  13.  
  14.  
  15. In article <1993Jan21.195804.6787@dbased.nuo.dec.com>, lionel@quark.enet.dec.com
  16. (Steve Lionel) writes:
  17. >Relax.  The default behavior hasn't changed.   The compiler sort of gives you
  18. >a free "SAVE" if it can't determine that you always store a variable before
  19. >using it.  But if you use /RECURSIVE, then variables not explicitly SAVEd
  20. >won't be.  Also, /RECURSIVE will eliminate guaranteed initialization to zero;
  21. >I've heard one customer consider this a feature, so as to ferret out hidden
  22. >bugs. 
  23.  
  24. Thanks, I was worried. I've also got code that counts on guaranteed
  25. initialization. I hadn't thought of that. So as long as I don't use /RECURSIVE,
  26. I should be OK, right?
  27.  
  28. >However, if you haven't SAVEd a variable, and the compiler can tell that you
  29. >definitely use it before storing it, it will give you a warning. 
  30.  
  31. Nice.
  32.  
  33. >Now what I said about SAVE not meaning "static" is true, though on VAX, at
  34. >least, it does force static allocation, even if you use /RECURSIVE.  But the
  35. >standard says you should use SAVE if you want the value saved, so put it in
  36. >if you mean that - it'll prevent possible surprises in the future and also
  37. >>makes
  38. >the intent clearer to someone reading the code.  
  39.  
  40. I always do, but I didn't write most of this stuff. Given sufficient time it'll
  41. all be rewritten in C anyway, Fortran's a poor choice for this application (it
  42. really needs dynamic memory), I just don't want it all to fall apart in the mean
  43. time.
  44.  
  45. Thanks for the reassurances!
  46. --
  47. Terry Poot <tp@mccall.com>                   The McCall Pattern Company
  48. (uucp: ...!rutgers!depot!mccall!tp)          615 McCall Road
  49. (800)255-2762, in KS (913)776-4041           Manhattan, KS 66502, USA
  50.