variable scoping broken ?

[jim_cox]

For your Friday amusement

Here's on odd one I found in v 11.01.048

If an integer variable is declared as intreger *4 in one routine

And then same variable name is declared but as integer*2 in another which calls the first

I find the value gets blown away when the subroutine gets called

eg:


SUBROUTINE GETFIL(FILENUM,IFILENAME,ERR1)

INTEGER*4 I

DO I=4,TRXMAXPATH
FILNM2(I) = FILE(I-3)
ENDDO

RETURN

END




and


PROGRAM MAIN

INTEGER*2 I

DO I=1,10

CALL GETFIL(999,CTEMP,ERR)

ENDDO




The value of I is "unpredictable" after the subroutine call

But all works fine if both dcelarations are Integer*4



Why?

[Steven_L_Intel1]

Your actual program is almost certainly different from the fragments you posted here. The issue is likely NOT name scoping, but rather argument mismatches. In your post above, you reference an undeclared variable FILNM2 which I assume is an array. If for example this was really a dummy argument in the subroutine and you passed a scalar to it, the assignment could overwrite memory in the caller. Building with /warn:interface would likely detect this.

If you still think there is a problem, then please post real code that demonstrates the issue.

[mecej4]

Your guess is wrong about the reasons for the behavior of your buggy program. If, indeed, variables in different program units overlaid one another or interacted in other ways, the whole concept of variable scope and independent compilation would be broken.

The code you showed has numerous errors, and cannot be compiled into a running program. Variables are used with default types that are wrong, and variable types do not match between subroutine declarations and invocations.

It is impossible to help when the code shown is not the one that produces the claimed run-time behavior.