views:

66

answers:

3

After much painful debugging, I believe I've found a unique property of Fortran that I'd like to verify here at stackoverflow.

What I've been noticing is that, at the very least, the value of internal logical variables are preserved across function or subroutine calls.

Here is some example code to illustrate my point:

PROGRAM function_variable_preserve
IMPLICIT NONE

CHARACTER(len=8) :: func_negative_or_not ! Declares function name
INTEGER :: input
CHARACTER(len=8) :: output

input = -9

output = func_negative_or_not(input)
WRITE(*,10) input, " is ", output
10 FORMAT("FUNCTION: ", I2, 2A)

CALL sub_negative_or_not(input, output)
WRITE(*,20) input, " is ", output
20 FORMAT("SUBROUTINE: ", I2, 2A)

WRITE(*,*) 'Expected negative.'


input = 7
output = func_negative_or_not(output)
WRITE(*,10) input, " is ", output

CALL sub_negative_or_not(input, output)
WRITE(*,20) input, " is ", output

WRITE(*,*) 'Expected positive.'

END PROGRAM function_variable_preserve

CHARACTER(len=*) FUNCTION func_negative_or_not(input)
IMPLICIT NONE

INTEGER, INTENT(IN) :: input
LOGICAL :: negative = .FALSE.

IF (input < 0) THEN
    negative = .TRUE.
END IF

IF (negative) THEN
    func_negative_or_not = 'negative'
ELSE 
    func_negative_or_not = 'positive'
END IF

END FUNCTION func_negative_or_not

SUBROUTINE sub_negative_or_not(input, output)
IMPLICIT NONE

INTEGER, INTENT(IN) :: input
CHARACTER(len=*), INTENT(OUT) :: output
LOGICAL :: negative = .FALSE.

IF (input < 0) THEN
    negative = .TRUE.
END IF

IF (negative) THEN
    output = 'negative'
ELSE 
    output = 'positive'
END IF

END SUBROUTINE sub_negative_or_not

This is the output:

FUNCTION: -9 is negative
SUBROUTINE: -9 is negative
 Expected negative.
FUNCTION:  7 is negative
SUBROUTINE:  7 is negative
 Expected positive.

As you can see, it appears that once the function or subroutine is called once, the logical variable negative, if switched to .TRUE., remains as such despite the initialization of negative to .FALSE. in the type declaration statement.

I could, of course, correct this problem by just adding a line negative = .FALSE. after declaring the variable in my function and subroutine.

However, it seems very odd to me that this be necessary.

For the sake of portability and code reusability, shouldn't the language (or compiler maybe) require re-initialization of all internal variables each time the subroutine or function is called?

+1  A: 

This isn't too different from static function-scoped variables in C or C++.

Programming language design was in its infancy, back when FORTRAN was developed. If it were being designed from scratch today, no doubt many of the design decisions would have been different.

Originally, FORTRAN didn't even support recursion, there was no dynamic memory allocation, programs played all sorts of type-punning games with COMMON blocks and EQUIVALENCE statements, procedures could have multiple entry points....so the memory model was basically for the compiler/linker to lay out everything, even local variables and numeric literal constants, into fixed storage locations, rather than on the stack. If you wanted, you could even write code that changed the value of "2" to "42"!

By now, there is an awful lot of legacy FORTRAN code out there, and compiler writers go to great lengths to preserve backward-compatible semantics. I can't quote chapter and verse from the standard that mandates the behavior you've noted, nor its rationale, but it seems reasonable that backward compatibility trumped modern language design sensibilities, in this instance.

Jim Lewis
There are undoubtedly some legacy issues in fortran which, were it written today from stratch, would be handled differently, but please - don't make it sound like it is a legacy language. Quite the opposite - in many terms it has features which other "modern" languages are quite from acquiring (for example, on c.l.f. discussions are often related to f03/newest C standard, which is what C99?)
ldigas
@Idigas: Good points! I didn't mean to imply that FORTRAN is a fossil...it's just that the legacy aspect seemed most on point to CmdrGuard's question, so that's what I focused on.
Jim Lewis
@Jim Lewis - Obviously, I misunderstood; sorry about that. My mistake. The rest of your answer is quite well put.
ldigas
+3  A: 

To answer your question: Yes Fortran does preserve the value of internal variables through function and subroutine calls.

Under certain conditions ...

If you declare an internal variable with the SAVE attribute it's value is saved from one call to the next. This is, of course, useful in some cases.

However, your question is a common reaction upon first learning about one of Fortran's gotchas: if you initialise an internal variable in its declaration then it automatically acquires the SAVE attribute. You have done exactly that in your subroutines. This is standard-conforming. If you don't want this to happen don't initialise in the declaration.

This is the cause of much surprise and complaint from (some) newcomers to the language. But no matter how hard they complain it's not going to change so you just have to (a) know about it and (b) program in awareness of it.

High Performance Mark
I believe (to be sure I would have to go check the Standard, which I don't have with me right now) that as of F2003, all variables have the SAVE attribute.
ldigas
Surprising indeed!
CmdrGuard
+1  A: 

This has been discussed several times here, most recently at http://stackoverflow.com/questions/3352741/fortran-assignment-on-declaration-and-save-attribute-gotcha

You don't have to discover this behavior by experimentation, it is clearly stated in the better textbooks.

Different languages are different and have different behaviors.

There is a historical reason for this behavior. Many compilers for Fortran 77 and earlier preserved the values of ALL local variables across calls of procedures. Programmers weren't supposed to rely upon this behavior but many did. According to the standard, if you wanted a local variable (non-COMMON) to retain its value you needed to use "SAVE". But many programmers ignored this. In that era programs were less frequently ported to different platforms and compilers, so incorrect assumptions might never be noticed. It is common to find this problem in legacy programs -- current Fortran compilers typically provide a compiler switch to cause all variables to be saved. It would be silly for the language standard to require that all local variables retain their values. But an intermediate requirement that would rescue many programs that were careless with "SAVE" would be to require all variables initialized in their declarations to automatically have the SAVE attribute. Hence what you discovered....

M. S. B.