Lost Memory

Lost Memory

What's wrong if a declared constant can't hold its value (i.e. it changes to zero after some times) throughout the program execution? .

4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

You have Windows 9X, passed the constant as an argument to a routine and that routine changed the value of the argument.


Retired 12/31/2016

Yes, that could cause various nasty behaviours. I feel inclined to write a debugging anecdote of mine. First, I spotted that the program does something wrong in routine called Validate:

integer function Validate(iValid)

which was called as:

j = Validate(VALID_TOPOLOGY)

The argument is declared as:

integer, parameter:: VALID_TOPOLOGY = 1

When I inspected value of iValid argument in the debugger, it was 47, which was meaningless. Hmmm, strange. I had to insert a "sanity check" line immediately before the call:


I rebuilt the application, and checked value of idummy in the debugger. It was 1 as expected. However, value of iValid was still 47. Have you seen "A Beautiful Mind?" :-)

(...an hour later)

The source of the problem lied in the call few dozen lines before the crazy one. Another routine was called like

call e_sin_ostrva(ierror,1)

It actually changed the value of constant "1&quot to 47. Compiler saw that the constant with value 1 was used twice as argument in the same routine (once as literal, once as PARAMETER), so it decided to reuse the same memory location, thus VALID_TOPOLOGY become 47. But then, how didn't it show in my "sanity check" line? Simply, compiler saw that I'm assigning a constant to a variable so it didn't bother to actually do the copying from one memory location to another; instead, it just translated the line as j=1.


The reason why Windows 9X is important is that it ignores the compiler's request to make constants read-only. Windows NT/2000/XP do the right thing.


Retired 12/31/2016

Leave a Comment

Please sign in to add a comment. Not a member? Join today