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 帖子 / 0 全新
最新文章
如需更全面地了解编译器优化,请参阅优化注意事项

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

Steve

Steve - Intel Developer Support

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

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.

Jugoslav

Jugoslav
www.xeffort.com

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

Steve - Intel Developer Support

发表评论

登录添加评论。还不是成员?立即加入