6

I'm dealing with some legacy code that uses COMMON blocks extensively and sometimes uses the SAVE statement. After consulting the Fortran standard, it says:

The appearance of a common block name preceded and followed by a slash in a SAVE statement has the effect of specifying all of the entities in that common block.

Under what circumstances does placing a variable in a common block not imply SAVE? Since the variable must be accessible in any other program unit that includes that common block, how could it not be SAVEed?

AstroCB
  • 12,337
  • 20
  • 57
  • 73
mgilson
  • 300,191
  • 65
  • 633
  • 696

2 Answers2

7

I had to look it up, because I was under the same impression as you are.

It seems that only variables in an unnamed, so-called blank, common block retain their definition status across the entire program. Unsaved variables in a named common block become undefined on return from a subprogram, unless another currently active program unit includes a common statement for the same common block.

From the standard (Fortran 77, but the latest one contains similar wording):

17.3 Events That Cause Entities to Become Undefined
[...]
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:
[...]
d. Entities in a named common block that appears in the subprogram and appears in at least one other program unit that is either directly or indirectly referencing the subprogram

eriktous
  • 6,569
  • 2
  • 25
  • 35
  • 2
    +1; wow, that's something that not only did I not know, I "knew" it exactly wrong. But on the other hand, I guess it's normally the case in practice that named common blocks are used precisely to share data throughout a call tree. Just another tricky reason never to use the darned things. – Jonathan Dursi Feb 24 '12 at 02:36
  • Be careful : the same rule applies to modules as well. In this area, COMMON and MODULES are equivalent. Fortunately in practice, I have never met a system deleting automatically the variables of a common or a module when this one becomes "out of scope". – Francois Jacq Feb 24 '12 at 16:04
  • @FrancoisJacq: I believe that was changed in the latest standard. All module variables now implicitly get the `save` attribute. – eriktous Feb 24 '12 at 16:36
  • Right but I don't know any F2008 compiler up to now and I don't expect such kind of compiler before several (many ?) years – Francois Jacq Feb 24 '12 at 19:44
  • @FrancoisJacq: True. You'd even still be hard pressed to find a f2003 compiler, unless you have access to an HPC center. – eriktous Feb 24 '12 at 23:44
  • Thanks, I had never really even considered that a f77 common block could "go out of scope". – mgilson Feb 27 '12 at 15:12
  • After reading the quote from the standard... doesn't that mean a **named** block would retain its state? ("Everything would become undefined, except for entities in named common blocks ...") –  Oct 09 '13 at 03:58
  • @Svetlana: only if the named common block also appears in a program unit higher up in the call tree. As an example, take a main program that calls two subroutines; if the main program doesn't contain the named common block, the two subroutines can not share data through it (assuming they don't directly call each other). – eriktous Oct 10 '13 at 11:54
4

Many compilers of the Fortran 77 era "saved" all local procedure variables, whether or not "SAVE" was specified. This is a common reason for legacy programs to fail with modern compilers, which will undefine variables when they go out of scope, as allowed by the language standard. Probably those older compilers would also maintain the values of all common variables for the duration of the program run, even though that wasn't required by the language standard.

M. S. B.
  • 28,968
  • 2
  • 46
  • 73
  • My understanding is that local procedure variables are typically allocated on the stack (although the f77 standard doesn't say anything about the stack/heap). I *thought* that common variables would have to be allocated on the heap since other program units need to be able to access them. The catch is that other program units must be called by a program unit containing the common block in order to ensure that the common block is defined (without an explicit save statement). Of course, it is probably easier for compilers to just allocate common blocks from the heap so that's how most behave. – mgilson Mar 12 '12 at 13:17