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.Steve
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 = 1When 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_TOPOLOGYI 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 likecall e_sin_ostrva(ierror,1)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. Jugoslav
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.Steve