views:

336

answers:

2

For my programming languages class one hw problem asks:

Are local variables in FORTRAN static or stack dynamic? Are local variables that are INITIALIZED to a default value static or stack dynamic? Show me some code with an explanation to back up your answer. Hint: The easiest way to check this is to have your program test the history sensitivity of a subprogram. Look at what happens when you initialize the local variable to a value and when you don’t. You may need to call more than one subprogram to lock in your answer with confidence.

I wrote a few subroutines: - create a variable - print the variable - initialize the variable to a value - print the variable again

Each successive call to the subroutine prints out the same random value for the variable when it is uninitialized and then it prints out the initialized value.

What is this random value when the variable is uninitialized?

Does this mean Fortran uses the same memory location for each call to the subroutine or it dynamically creates space and initializes the variable randomly?

My second subroutine also creates a variable, but then calls the first subroutine. The result is the same except the random number printed of the uninitialized variable is different. I am very confused. Please help!

Thank you so much.

+2  A: 

In Fortran 77 & 90/95/2003, if you want the value of a variable local to a subroutine preserved across subroutine calls, you should declare it the "save" attribute, e.g., (using Fortran 90 style):

integer, save :: counter

OR

integer :: counter
save :: counter

. Or, if you want the "save" behavior to apply to all variables just include in the subroutine a simple

save

statement without any variables. In Fortran 90, a variable initialization in a declaration,

integer :: counter = 0

automatically acquires the save attribute. I don't think that this was the case in Fortran 77.

This is one area in which experiments could be misleading -- they will tell you what a particular compiler does, but perhaps not what the Fortran 77 language standard is, nor what other compilers did. Many old Fortran 77 compilers didn't place local variables on the stack and implicitly all variables had the save attribute, without the programming having used that declaration. This, for example, was the case with the popular DEC Fortran compilers. It is common for legacy Fortran 77 programs that were used only with a particular compiler of this type to malfunction with a modern compiler because programmers forgot to use the save attribute on variables that needed it. Originally this didn't cause a problem because all variables effectively had the save attribute. Most modern compilers place local variables without save on the stack, and these programs frequently malfunction because some variables that need "save" "forget" their values across subroutine calls. This can be fixed by identifying the problem variables and adding save (work), adding a save statement to every subroutine (less work), or many compilers have an option (e.g., -fno-automatic in gfortran) to restore the old behavior (easy).

It seems a peculiar question -- you won't find out about "Fortran 77" but about a particular compiler. And why use Fortran 77 instead of Fortran 95/2003? Does the prof. think Fortran stopped in 1977?

M. S. B.
To add to my answer and High Performance Mark's: what you are exploring is "undefined" -- when you examine the value of a local variable without the save attribute on a second invocation of a subroutine, without reinitializing that variable, you have violated the language standard and the behavior is undefined. Anything might happen, depending on the implementation of the particular compiler. If the variables are on the stack, you will see some "random" value. If they are placed at a fixed memory location, you will see the previous value.
M. S. B.
+2  A: 

To amplify on one point that @MSB made;

Fortran standards do not tell compiler-writers how to implement the standards, they are concerned with the behaviour of programs visible to the programmer. So the answer to the question is 'it all depends on the compiler'. And OP does not tell us which compiler(s) (s)he is using.

Furthermore, if you trawl back through the mists of time to examine all the FORTRAN77 compilers ever written, I am confident that you will find a wide variety of different implementations of the features you are interested in, many of them tied to quite esoteric hardware architectures.

High Performance Mark