pmk@craycos.com (Peter Klausler) (02/20/91)
Last week, I posted a note stating that DATA-initialized variables do not require a SAVE statement to survive between invocations of a subprogram. Several respondents and e-mail correspondents have pointed out to me that this is NOT the case in the '77 standard. (There's nothing like posting misinformation to flush old friends out of the woodwork. You may assume that to be my motive the next time I'm wrong...) The relevant paragraphs are those at the end of page 8-11 in the standard. I did peruse the standard before posting, but missed this text. My confusion stemmed from having worked with (and on) implementations in which DATA initialization causes static storage to be used for a variable. I would like to know of implementations of Fortran in which one can actually get into trouble by assuming DATA implies SAVE in one's program, and why, in terms of the implementation.
burley@geech.ai.mit.edu (Craig Burley) (02/22/91)
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