richardh@killer.UUCP (Richard Hargrove) (12/30/87)
A quick question for serious FORTRAN user's: do the semantics of initializing
a local variable in a DATA statement force the variable to have static
scope? That is, can you generally count on the variable retaining its value
across calls to the subroutine in which it's defined? I know this is the case
for some compilers, but can you count on it generally? F77 and no, I don't
have a copy of the standard.
thanks,
richard hargrove
...{ihnp4|codas|cbosgd}!killer!richardh
---------------------------------------carols@drilex.UUCP (Carol Springs) (12/31/87)
In article <2617@killer.UUCP> richardh@killer.UUCP (Richard Hargrove) writes: >A quick question for serious FORTRAN user's: do the semantics of initializing >a local variable in a DATA statement force the variable to have static >scope? That is, can you generally count on the variable retaining its value >across calls to the subroutine in which it's defined? I know this is the case >for some compilers, but can you count on it generally? F77 and no, I don't >have a copy of the standard. The ANSI standard for FORTRAN77 does not specify that DATA variables retain their values across subroutine calls. There are implementations of FORTRAN77 for which one cannot count on these variables' keeping the value most recently assigned to them in the subprogram--for example, Unisys A Series FORTRAN77 (unless the compiler control option OWN is set). If memory serves correctly, the default action in A Series FORTRAN77 is to restore the DATA-initialized values to all such variables every time the subroutine is invoked. If a variable is not changed within the procedure, the user sees the same value for the variable in each invocation, whether or not OWN is set. If, however, the variable is reassigned, different results can occur depending on the setting of OWN. Moral: Don't count on *any* local variables' keeping their values from one subprogram invocation to the next, especially if you want to ensure portability. Include the variables in SAVE statements if necessary. -- Carol Springs Data Resources/McGraw-Hill {rutgers!ll-xn, ames!ll-xn, mit-eddie!ll-xn, 24 Hartwell Avenue husc6!harvard, gatech!harvard, Lexington, MA 02173 linus!axiom, necntc} !drilex!carols
cdb@hpclcdb.HP.COM (01/02/88)
> A quick question for serious FORTRAN user's: do the semantics of initializing > a local variable in a DATA statement force the variable to have static > scope? That is, can you generally count on the variable retaining its value > across calls to the subroutine in which it's defined? I know this is the case > for some compilers, but can you count on it generally? F77 and no, I don't > have a copy of the standard. > The Fortran 77 standard says that you can't depend on it (Page 8-11, lines 33-42, if you want to look it up). As a practical matter, the compiler would have to go to a lot of trouble and produce a lot of extra code to break this assumption - I've only heard rumors of one compiler that didn't make these values saved. It supposedly did/does assignments to the initialized locals to implement DATA, thereby trashing any previously changed values - and slowing down the program unnecessarily. Given the availability of the SAVE statement in standard F77, why worry - SAVE it! Carl Burch hplabs!hpda!cdb
firth@sei.cmu.edu (Robert Firth) (01/04/88)
In article <2617@killer.UUCP> richardh@killer.UUCP (Richard Hargrove) writes: >A quick question for serious FORTRAN user's: do the semantics of initializing >a local variable in a DATA statement force the variable to have static >scope? That is, can you generally count on the variable retaining its value >across calls to the subroutine in which it's defined? I know this is the case >for some compilers, but can you count on it generally? F77 and no, I don't >have a copy of the standard. The quick answer: No. You'll find it in ANSI X3.9-1978 para 17.3 (6) "The execution of a RETURN statement or an END statement within a subprogram causes all entities within the subprogram to become undefined except for the following: ... (b) Initially defined entities that have neither been redefined nor become undefined ... " In other words, if you haven't yet assigned to the variable, it will retain its initial value (as given in the DATA statement); if you have assigned to it (or caused it to become undefined in any of the many ways allowed by Fortran), then it is NOT guaranteed to retain any value between invocations of the subprogram. As you say, most compilers will let you get away with this, since they make the variables static. However, there are other legitimate implementations. If you want to follow the standard, don't ever assume more than it guarantees.
levy@ttrdc.UUCP (Daniel R. Levy) (01/09/88)
In article <3669@aw>, firth@aw writes: #> In article <2617@killer.UUCP> richardh@killer.UUCP (Richard Hargrove) writes: #> >... [does] a DATA statement force ... [a] variable to have static #> >scope? #> #> The quick answer: No. #> #> You'll find it in ANSI X3.9-1978 para 17.3 (6) #> "The execution of a RETURN statement or an END statement #> within a subprogram causes all entities within the subprogram #> to become undefined except for the following: #> ... #> (b) Initially defined entities that have neither been redefined #> nor become undefined #> ... #> " #> As you say, most compilers will let you get away with this, since they make #> the variables static. However, there are other legitimate implementations. #> If you want to follow the standard, don't ever assume more than it guarantees. This kind of behavior can also be assured by using the SAVE statement, e.g., DATA FOO /1.0/ ... SAVE FOO -- |------------Dan Levy------------| Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, | an Engihacker @ | <most AT&T machines>}!ttrdc!ttrda!levy | AT&T Computer Systems Division | Disclaimer? Huh? What disclaimer??? |--------Skokie, Illinois--------|