12.1 Using Common Blocks 

For example, in a simple package to handle a pen-plotter you may want to provide simple procedure calls such as:

CALL PLOPEN Initialise the plotting device CALL SCALE(F) Set the scaling factor to F. CALL MOVE(X,Y) Move the pen to position (X,Y) CALL DRAW(X,Y) Draw a line from the last pen position to (X,Y).

These procedures clearly have to pass information from one to another about the current pen position, scaling factor, etc. A suitable common block definition might look like this:

COMMON /PLOT/ OPENED, ORIGIN(2), PSCALE, NUMPEN         LOGICAL OPENED         INTEGER NUMPEN         REAL PSCALE, ORIGIN         SAVE /PLOT/

These specification statements would be needed in each procedure in the package.

Common Block Names 

A program unit can access the contents of any common block by quoting its name in a COMMON statement. Common block names are always enclosed in a pair of slashes and can only be used in COMMON and SAVE statements. The common block itself has no data type and has a global name which must be distinct from the names of all program units. The name should also be distinct from all local names in each program units which access the block. Each program unit can make use of any number of different common blocks. There is also a special blank or un-named common block with unique properties which are covered in section 12.2 below.

The variables and arrays within a common block do not have any global status: they are associated with items in blocks bearing the same name in other program units only by their position within the block. Thus, if in one program unit specifies:

COMMON /OBTUSE/ X(3)

and in another:

COMMON /OBTUSE/ A, B, C

then, assuming the data types are the same, X(1) corresponds to A, X(2) to B, and X(3) to C. The COMMON statements here are effectively setting up different names or aliases for the same set of memory locations. The data types do not have to match provided the overall length is the same, but it is generally only possible to transfer information from one program unit to another if the corresponding items have the same data type. If they do not, when one item becomes defined all names for the same location which have a different data type become undefined. There is one minor exception to this rule: information may be transferred from a complex variable (or array element) to two variables of type real (or vice-versa) since these are directly associated with its real and imaginary parts.

Usually it is necessary to arrange for corresponding items to have identical data types; it also minimises confusion if the same symbolic names are used as well. The simplest way to achieve this is to use an INCLUDE statement, if your system provides one. The include-file should contain not only the COMMON statement but also all the associated type and SAVE statements which are necessary. It is, of course, still necessary to recompile every program unit which accesses the common block whenever its definition is altered significantly.

Declaring Arrays 

The bounds of an array can be declared in the COMMON statement itself, or in a separate type or DIMENSION statement, but only in one of them. Thus:

COMMON /DEMO/ ARRAY(5000)         DOUBLE PRECISION ARRAY

is exactly equivalent to:

COMMON /DEMO/ ARRAY         DOUBLE PRECISION ARRAY(5000)

or even:

COMMON /DEMO/ ARRAY         DOUBLE PRECISION ARRAY         DIMENSION ARRAY(5000)

but the verbosity of the third form has little to recommend it.

Data Types  

The normal data type rules apply to variables and arrays in each common block. A type statement is not required if the initial letter rule would have the required effect, but type statements are advisable, especially if the implied-type rules are anywhere affected by IMPLICIT statements. Type statements may precede or follow the COMMON statement. Similarly the lengths of character items should be specified in a separate type statement: these cannot be specified in the COMMON statement.

Storage Units 

The length of each common block is measured in storage units, as described in section 5.1. In summary, integer, real, and logical items occupy one numeric storage unit each; complex and double precision items occupy two each. To maximise portability, character storage units are considered incommensurate with numerical storage units. For this reason character and non-character items cannot be mixed in the same common block.

In practice this often means that two common blocks are needed to hold a particular data structure: one for the character items and one for all the others. If, in the first example, it had been necessary for the plotting package to store a plot title this would have to appear in a separate common block such as:

COMMON /PLOTC/ TITLE         CHARACTER TITLE*40         SAVE /PLOTC/

It is good practice to use related names for the blocks to indicate that the character and non-character items are used in conjunction.

The length of a named common block must be the same in each program unit in which it appears. Obviously the easiest way to ensure this is to make the common block contents identical in each program unit. Note, however, that there is no requirement for data types to match, or for them to be listed in any particular order, provided the items are not used for information transfer, and provided the total length of the block is the same in each case. Thus these common blocks are both 2000 numerical storage units in length:

COMMON /SAME/ G(1000)         DOUBLE PRECISION G           COMMON /SAME/ A, B, C, R(1997)         REAL A, R         LOGICAL B         INTEGER C

Items in a common block are stored in consecutive memory locations. Unfortunately there a few computer systems which require double precision and complex items to be stored in even-numbered storage locations: these may find it hard to cope with blocks which contain a mixture of data types. Machines with this defect can nearly always be placated by arranging for all double precision and complex items to come at the beginning of each block.

SAVE Statements and Common Blocks 

Items in common blocks may become undefined when a procedure returns control to the calling unit just like local variables and arrays. This will not, however, occur in the case of the blank common block nor in any common block which is also declared in a program unit which is higher up the current chain of procedure calls. Since the main program unit is always at the top of the chain any common block declared in the main program can never become undefined in this way. In all other cases it is prudent to use SAVE statements.

The individual items in common blocks cannot be specified in a SAVE statement, only the common block name itself. Thus:

SAVE /SAME/, /DEMO/

If a common block is saved in any program unit then it must be saved in all of them. The SAVE statement ought therefore to be included with the COMMON and associated type statements if INCLUDE statements are used. If the program is later modified so that the common block is also declared in the main program this will bring a SAVE statement into the main program unit, but although it then has no effect, it does no harm.

Restrictions 

The dummy arguments of a procedure cannot be members of a common block nor, in a function, can the variable which has same name as the function. There are also some restrictions on the use of common block items as actual arguments of procedure calls because of the possibility of multiple definition. For example, if a procedure is defined like this:

SUBROUTINE SILLY(ARG)         COMMON /BLOCK/ COM

And the same common block is also used in the calling unit, with a common block item as the actual argument, such as:

PROGRAM DUMMY         COMMON /BLOCK/ VALUE  *...         CALL SILLY(VALUE)

Then both ARG and COM within the subroutine SILLY are associated with the same item, VALUE, and it is therefore illegal to assign a new value to either of them.