You're asking for quite a bit here. There are lots of ways to introduce errors. The most obvious is to try inserting a common in the midst of executable statements. It belongs up with DIMENSIONs, PARAMETER's, SAVE's, and the rest of the non-executables. A more subtle problem is the use of multiple COMMON statements for blank common or the same named common. Fortran will accept the following program:

However, the values printed out are 1.0 and 2.0. The second common statement in the main program just tacks the variables "c" and "d" onto blank common after "b". The two commons together are equivalent to "common a,b,c,d". In the subroutine you are saying that "c" is the FIRST element in blank common, so Fortran associates "c" in "sub1" with the same address in memory as assigned to "a" in the main program. Also recall that mixing reals and integers (common/blk1/a,b,i,c) when the reals are DOUBLE precision may CAUSE errors on some machines, and is not a good IDEA on any 32 bit machine.

You're asking for quite a bit here. There are lots of ways to introduce errors. The most obvious is to try inserting a common in the midst of executable statements. It belongs up with DIMENSIONs, PARAMETER's, SAVE's, and the rest of the non-executables. A more subtle problem is the use of multiple COMMON statements for blank common or the same named common. Fortran will accept the following program:

However, the values printed out are 1.0 and 2.0. The second common statement in the main program just tacks the variables "c" and "d" onto blank common after "b". The two commons together are equivalent to "common a,b,c,d". In the subroutine you are saying that "c" is the first element in blank common, so Fortran associates "c" in "sub1" with the same address in memory as assigned to "a" in the main program. Also recall that mixing reals and integers (common/blk1/a,b,i,c) when the reals are double precision may cause errors on some machines, and is not a good idea on any 32 bit machine.