- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
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?
Link Copied
2 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
If you still think there is a problem, then please post real code that demonstrates the issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page