[comp.lang.fortran] Question on DATA and SAVE.

smryan@garth.UUCP (s m ryan) (01/28/89)

Does anyone have an opinion or knowledge of whether it is meaningful to
initialise a local variable of a subprogram with a DATA but not SAVE the
variable? It would seem the variable can become undefined on entry so that
the DATA would be ignored.

--------------------------------

Going through X3.9-1978 I saw the following in Appendix B:

All combinations of connect and exist are possible, for example

connect   exist
 ...       ...
  no        no     The reel of tape destroyed in the fire last week.
-- 
When it was caught, then Loki said,                                   -s m ryan
`What fish is this from river's bed?
Your doom is near; to Hel you'll fly                           -- Andwari's Gem
unless with gold your life you buy.'                                    -- 1/10

hirchert@uxe.cso.uiuc.edu (01/30/89)

S. M. Ryan (smryan@garth.UUCP) asks
>Does anyone have an opinion or knowledge of whether it is meaningful to
>initialise a local variable of a subprogram with a DATA but not SAVE the
>variable? It would seem the variable can become undefined on entry so that
>the DATA would be ignored.

I have heard of two uses:
1. Since, the variable will not become undefined on the next entry if it is
   not redefined on this entry, such variables can be used as "constants".
   This is most appropriate for table lookups or other array "constants".
   [BTW, the Fortran 8x draft included real array constants,  so this aspect
   is not needed in F8x.]
2. Since the variable is guaranteed to be defined on the first entry, this
   may be appropriate for subprograms that are referenced only once during the
   execution of a program (e.g. initialization or termination logic).

BTW, in the Fortran 8x draft, DATA implied SAVE, so this question would be
moot in F8x.

Kurt W. Hirchert     hirchert@ncsa.uiuc.edu
National Center for Supercomputing Applications

ags@s.cc.purdue.edu (Dave Seaman) (01/30/89)

In article <2482@garth.UUCP> smryan@garth.UUCP (s m ryan) writes:
>Does anyone have an opinion or knowledge of whether it is meaningful to
>initialise a local variable of a subprogram with a DATA but not SAVE the
>variable? It would seem the variable can become undefined on entry so that
>the DATA would be ignored.

Only if the variable was redefined or became undefined at some earlier
time.  If the variable was never modified, then the DATA remains in effect
throughout the life of the program.  This would be useful for setting up
constant arrays for table lookup.  See the last paragraph of section 8.9.

-- 
Dave Seaman	  					
ags@j.cc.purdue.edu

weyrich@csun1.UUCP (Orville Weyrich) (01/31/89)

From article <2482@garth.UUCP>, by smryan@garth.UUCP (s m ryan):
> Does anyone have an opinion or knowledge of whether it is meaningful to
> initialise a local variable of a subprogram with a DATA but not SAVE the
> variable? It would seem the variable can become undefined on entry so that
> the DATA would be ignored.

Without the SAVE, you can count on a data-initialized variable to have the
specified initial value the first time you enter the subroutine. If the
subroutine changes the value of the data initialized variable, then the
value which you find on subsequent entries into the subroutine is "undefined"
by the FORTRAN standard. In practice, this means the value is 
"system-dependent".  For example, IBM mainframe FORTRAN-G will allow the
variable to retain its previous value between subroutine calls IF YOU DO
NOT OVERLAY the subroutine.  If the subroutine is overlayed and the overlay
is swapped out, then when you enter the subroutine again, the initial data-
initialized value is reincarnated. Some other compilers (Burroughs???)
allocate variables which are not marked with a SAVE on a local stack
and the values are garbage when you reenter (I know this only by hearsay,
and am not sure what happens with DATA initialized variables on the
Burroughs).

The bottom line -- either use SAVE if variables need to preserve changes in
their values across subroutine calls or else get real intimate with your
particular implementation of FORTRAN (not recommended :-( ).


-- 
Orville R. Weyrich, Jr.          | UUCP    : ...gatech!csun1!weyrich
Department of Computer Science   | INTERNET: weyrich@csun1.cs.uga.edu
University of Georgia            |
Athens, GA 30602 USA             | MA BELL : (404) 542-1082

BVAUGHAN@pucc.Princeton.EDU (Barbara Vaughan) (01/31/89)

In article <2482@garth.UUCP>, smryan@garth.UUCP (s m ryan) writes:

>Does anyone have an opinion or knowledge of whether it is meaningful to
>initialise a local variable of a subprogram with a DATA but not SAVE the
>variable? It would seem the variable can become undefined on entry so that
>the DATA would be ignored.

Back in the old days, pre F77, some Fortran compilers caused reinitial-
ization of local variables; others didn't. SAVE was not part of the
Fortran vocabulary. Even now, some F77 compilers allow you to specify
as a compile option that local variables should automatically be saved,
in which case the SAVE statement need not be used.

If you want to know why an existing program might have this peculiarity,
I hope this answer helps. If you want to know whether a reasonable
person would write code like this, the answer is 'no'.

Barbara Vaughan

bill@hcx2.SSD.HARRIS.COM (02/01/89)

As far as X3.9-1978 goes, the answer is somewhat complicated.  See
page 8-11, lines 35-50.  What this says is that, if the variable
has never been defined or become undefined, it still retains the
DATA value.  But once you assign to it or otherwise make it become
undefined (like passing it as an actual to a dummy that might, or
might not, be redefined), then it (the DATA variable) becomes undefined
upon executing a RETURN or END.

Remember that "undefined" in the Standard means that you can't count
on its value.  It does NOT mean that the value has necessarily changed.

As far as practicality goes, this program is non-portable.  There are
some implementations that execute such a DATA statement, where the
variable is not SAVEd, each time the procedure is entered.  Others
do not.  

Note that the current draft 8x standard says that DATA implies the SAVE
attribute; FORTRAN/77 did not say that.

Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
bill@ssd.harris.com or bill%ssd.harris.com@eddie.mit.edu