Named common blocks with different sizes

[hweisberg]

The CVF documentation says, "Named common blocks must be declared to have the same size in each program unit. Blank common can have different lengths in different program units."

The following code violates the above rule. But it works, provided array and string bounds runtime checking is off:

program test
common /a/ array(1)
print *, array(2) !Prints 99.00000
end

block data
common /a/ array(2)
data array(2) /99/
end

Is there a way to accommodate code like this in a reliable way? Is the fact that the code works based on undocumented behavior, which could change?

[james1]

The problem with this sort of code is it is really up to the linker to get it right, all the compiler can do is declare the data section with a given size, and when multiple declarations conflict, the compiler cannot do anything to ensure that the linker can figure it out.

James

[Steven_L_Intel1]

James is correct. Furthermore, you risk the possibility of data corruption if the linker chooses the shorter length for allocation.

CVF provides, in the USUPPORT folder on the CD-ROM, a program called CBANLW (Common Block Analyzer for Windows). You feed it all your .OBJ files (it supports drag and drop) and it tells you if it finds inconsistencies in lengths.

Steve

[hweisberg]

Well, I already know there are inconsistencies in named common block lengths in our code -- thousands if not tens of thousands of them.

We seem to have three options:

1. Hope for the best -- not a winning strategy.

2. Find a way to force the linker to do what we want it to do (and what it already seems to do anyhow) -- perhaps the best option if feasible.

3. Add to our code porting precompiler the feature of padding named common blocks with dummy variables to make them all come out to the same length -- wouldn't be too hard to do but is ugly.

Perhaps someone on the forum can suggest how to do option (2).

[Steven_L_Intel1]

No good way to do #2 - I think the MS linker uses the length of the first contribution to the common block it sees. Unless you can rigorously enforce the link order, you're left to random chance.

Steve

[hweisberg]

I could create a Block Data file that includes all of the common blocks at issue, with the proper lengths. Is there some way to arrange that the linker sees this file first?

[Steven_L_Intel1]

I can't recommend this - there's no guarantee that the linker (any particular linker) will always handle inconsistent lengths in the same way. If you were going to try this, you would have to do the link on the command line and explicitly specify the objects in the right order. Very risky in my opinion.

Why not 1) use INCLUDE files, or 2) use MODULE variables instead of COMMON?

Steve