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? .
You have Windows 9X, passed the constant as an argument to a routine and that routine changed the value of the argument.
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:
idummy = VALID_TOPOLOGY
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
It actually changed the value of constant "1" 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.