Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!think.com!mintaka!mintaka.lcs.mit.edu!burley From: burley@geech.ai.mit.edu (Craig Burley) Newsgroups: comp.lang.fortran Subject: Re: SAVE and DATA Message-ID: Date: 21 Feb 91 16:34:26 GMT References: <1991Feb19.163148.7204@craycos.com> <1991Feb20.153932.16739@ncsa.uiuc.edu> Sender: daemon@mintaka.lcs.mit.edu (Lucifer Maleficius) Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139 (617) 253-8568 Lines: 58 In-Reply-To: hirchert@ncsa.uiuc.edu's message of 20 Feb 91 15:39:32 GMT In article <1991Feb20.153932.16739@ncsa.uiuc.edu> hirchert@ncsa.uiuc.edu (Kurt Hirchert) writes: [In the development of Fortran 90, this overlay model was no longer seen as being significant, so DATA _does_ imply SAVE in Fortran 90.] I looked up some stuff in the '77 standard to try and understand what it really says about a DATAd variable not SAVEd. My interpretation of the standard is this: If you DATA a local variable/array but don't SAVE it in a procedure (SAVE has no meaning in a main program; local variables are meaningless in a BLOCK DATA), then the variable/array is defined when the program starts running. Now, when the procedure returns, the variable/array is still defined (and thus defined when the procedure is next invoked) UNLESS you have redefined or undefined it in the meantime. In other words, this procedure is invalid the second time it is invoked SUBROUTINE X DATA I/3/ PRINT *,I I = I + 1 END and subsequent times, because the first time it is invoked, it redefines I, thus I becomes undefined when X returns. Subsequent invocations fail to redefine I before attempting to print its value, so X is invalid. (The standard does not say that the DATA statement defines a value each time a procedure is invoked; so a conforming system would not have to redefine I to be 3 for subsequent invocations, though it could if it wanted.) Remove the "I = I + 1" line, and the subroutine is fine each and every time it is invoked, because I is neither redefined nor undefined during any invocation. Ok, so this is my interpretation. My question is: am I essentially correct in this interpretation? Also, it seems this allows overlay managers (described in previous postings) to record only the initial values for such variables, but not keep track of redefined values of those variables. So an overlay manager might well execute the above X subroutine the second time with I still set to 3, the value previously set (4) having been lost because the new value was not written back out to the overlay backing store. Does this make any sense? I don't mean "is this useful", but is this sort of behavior the kind of thing the 77 standard was designed to allow? It makes sense to me, as someone who has suffered under overlay-based systems in the ancient and dark past. I doubt I'll ever use this information -- I can't imagine people would want GNU Fortran to do this stuff, for one thing -- but I'm curious anyway. Email me if you like, unless you have a nice definitive response to post! (Hint, hint, Kurt! :-) -- James Craig Burley, Software Craftsperson burley@ai.mit.edu