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