Replacing COMMON blocks with modules in f77 code

[ar11_91]

Dear Community,

I have read a number of interesting posts about this subject, still I have some questions. I also read that some wise members of this community advised against doing this replacement ("if it ain't broke ...", and I kind of agree), but this is a mandatory task for me.

* in routine 1, I have a COMMON as below

PARAMETER(NA=25)
COMMON /MATL/ TFG(NA)

* same COMMON is set in routine 2 but NA is now 1024:

PARAMETER(NA=1024)
COMMON /MATL/ TFG(NA)

* if I would want to replace COMMON MATL with a module, would it be possible not to fix array size TFG in the module, such as

real TFG(*)

for instance, without getting a compilation problem ? I think this is incorrect. Would it be a correct way of doing it, and is it even possible ?

Thanks in advance for your help,

A.

[Steve_Lionel]

The code as you have it is not legal Fortran. A named COMMON must have the same size in all program units, and on some systems this would lead to data corruption. (If it was "blank" (unnamed) COMMON, it would be allowed.)

What are you using this COMMON for and why is the size different in different subroutines?

[ar11_91]

Dear Steve_Lionel,

Thank you for answering.

Well, that is a good question. It also puzzled me a lot This is a research code I am working with, and it is 30+ years old. So far it seemed to work OK without issue I guess all of it is just bad programming. Thank you for confirming that.

[Steve_Lionel]

There's lots of bad code out there that "seems to work OK" - until something changes and it suddenly breaks.

COMMONs can often be replaced by module variables, though if the program makes use of the "storage association" aspect of COMMON, taking advantage of the knowledge of the layout in memory, that can be harder. What you have looks like it might be used as temporary storage ("work area") per routine. There are other ways of handling this - a simple one is just not putting the variable in COMMON so it would be local to each routine. The default (in the oneAPI compiler) is that all routines are recursive-capable, so the array would be put on the stack for the duration of the routine, and then automatically go away. But if the program assumes values will stay around across calls, or uses it to share values across routines, a module variable would be more appropriate.