Fortran 77 注释掉 write 语句的错误
我正在使用一个旧的 FORTRAN 77 程序，并且遇到了一个奇怪的错误。按原样，代码似乎运行良好，并在不到一秒的时间内完成。但它会产生一堆我不感兴趣的无关输出。因此，我进入源代码，并注释掉所有额外的 WRITE 语句。
好吧，当我注释掉一些 WRITE 语句时，代码似乎运行得有点慢（尽管我对此不确定；它可能看起来更慢，因为我滚动的文本行较少，让我忙碌） 。当我注释掉最后一个额外的 WRITE 语句时，程序只是挂起，并且永远不会完成执行。
现在，从逻辑上讲，注释掉 WRITE 语句仍然应该使程序的其余部分完全正常工作，对吧？我认为这意味着代码中潜伏着一些其他问题，并且 WRITE 语句以某种方式掩盖了它（也许是清除缓冲区？）。
一位了解 Fortran 的同事（少数之一）建议我可能无意中注释掉了一个语句标签，但事实并非如此。另一位不懂 Fortran 但总体上非常擅长编程的同事表示，这对他来说听起来像是一个指针问题，但据我所知，我从来没有将越界索引传递给数组，我不确定还会如何出现这样的问题。
我正在 PowerPC Mac 计算机上使用 g77 编译该程序。
I'm working with an old FORTRAN 77 program, and I've encountered a bizarre bug. As-is, the code appears to run fine, and finishes in less than a second. But it produces a bunch of extraneous output that I'm not interested in. So, I went into the source, and commented out all of the extra WRITE statements.
Well, when I comment out a few of the WRITE statements, the code seems to run a little slower (though I'm not sure about that; it might just seem slower since I have fewer lines of text scrolling by to keep me occupied). And when I comment out the last of the extra WRITE statements, the program just hangs, and never finishes executing.
Now, logically, commenting out a WRITE statement should still leave the rest of the program fully functional, right? I presume what this means is that there's some other problem lurking somewhere in the code, and that the WRITE statement is somehow masking it (clearing out a buffer, maybe?).
A colleague who knows Fortran (one of the few) suggested that I might have inadvertently commented out a statement label, but that's not the case. Another colleague who doesn't know Fortran, but is very skilled with programming in general, suggested that it sounded to him like a pointer problem, but so far as I can tell I'm never passing an out-of-bounds index to an array, and I'm not sure how else such a problem would come about.
I'm compiling the program using g77, on a PowerPC Mac computer.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这听起来似乎麻木不仁，甚至可能很粗鲁，但是......
标准答案 1 在这里适用 - 如果你理解这个问题，你就不会寻求帮助。如果你想获得像样的帮助，你需要展示实际的问题，而不是你对你认为问题所在的解释。我们无法通过查看不是要调试的代码的内容来调试代码，甚至可能不是问题的根源。
因此，请显示代码！
- 声明很重要
- 如何编译它，打开哪些选项？
- 跨出数组边界是编译器应该在编译时捕获的事情
- 是写语句写入屏幕或其他单元（文件）；有没有机会稍后从中读取某些内容？
- 可能是保存和初始化值的问题吗？ （只是在这里猜测）
你说程序“挂起”。您是否尝试过确定它挂在代码的哪一部分？ （无限循环），或者它刚刚进入某种较长的循环？
我已经见过几次“评论打印语句”错误（事实上，最后一次是最近一次），并且在挑选出无关紧要的位后，它总是在开始时就应该是显而易见的。所以，慢慢来......尝试开始，踢掉程序中不会导致错误消失的部分，然后从那里开始工作。
从提供的信息中确实没有什么可以说的了，抱歉。
编辑：@bambeck - 我没有 g77（也没有powerMac），所以我无法给你准确的说明（因此我的部分含糊不清），但首先尝试打开编译器诊断开关（g77 /？或 g77 /help 或类似的东西应该给你一个它们的列表） 。使其能够显示所有警告（应该用类似的措辞）、编译时的数组边界检查等等...如果这会产生一些有趣的，请发布它。
就这一点而言，您所显示的写入语句本身没有任何问题。
我也不知道这个循环是否真的是无限的，但它持续了半个多小时。不过，关于保存的部分看起来很有希望……详细一点？
哦，只是突然想到的一些事情。我不确定标准对此有何规定，这就是为什么我只是在旁边提到它。有时，当数组未正确初始化（某个值）时，一些编译器会将其设置为零值，而另一些编译器只会从存储其内容的位置的内存中随机选取一些内容。我们曾经遇到过类似的问题，它给了我们一些奇怪的结果，这就是为什么我记得它。并不是说你也有同样的问题。在这些情况下，SAVE 语句可能会引入一些奇怪的行为。
您的结果（当程序“工作”时）在不同的运行（使用相同的输入数据）上是否有所不同？
This is going to sound insensitive, maybe even rude but ...
Standard answer number 1 applies here - if you understood the problem you would not be asking for help. If you want any odds of getting decent help, you need to show the actual problem rather than your interpretation of something that you think the problem is. We can't debug code by looking at something that isn't the code to be debugged, or maybe even the source of the problem.
So, show the code!
- declarations matter a lot
- how do you compile it, what options are turned on?
- stepping out of array bounds is something the compiler should catch at compile time
- is the write statement writing out to screen or to some other unit (file); is there a chance something is read later from it?
- could it be the problem with save and initialized values? (just guessing here)
You said program "hangs". Have you tried determining into what part of code it hangs? (infinite loop), or has it just entered into a longish loop of some kind?
I've seen the "commenting the print statement" error a few times (the last time quite recently in fact), and upon picking out the insignificant bits, it always turned out to be something that should've been obvious at start. So, just take it slow ... try for a start, kicking out the parts of the program that don't cause the error to go away, and work from there.
There is really nothing more that could be said from the provided info, sorry.
Edit: @bambeck - I don't have g77 (nor a powerMac), so I cannot give you exact instructions (therefore the vagueness on my part), but for a start try turning on compiler diagnostic switches (g77 /? or g77 /help or something like that should give you a list of them). Enable it to show all warnings (it should be phrased something like that), array-bounds checking at compile time and so on... If that produces something interesting, post it.
There is nothing per se wrong with the write statement you've shown, as far as that's concerned.
Nor do I know if the loop is truly infinite, but it goes for over half an hour. The bit about save looks promising, though... Elaborate?
Oh, just some thing that sprang to mind. I'm not sure what the Standard says aboit it, that's why I just mentioned it on the side. Sometimes when the array is not initialized properly (to some value) some compilers will set it to zero value while some will just pick something random from memory at the location where it's contents are stored. We had a problem with something similar once, and it gave us some weird results, that's why I remembered it. Not saying you have the same problem. SAVE statement in those cases could introduce some weird behaviour.
Do your results (when the program "works") ever differ on different runs (with the same input data)?
1）您通常可以编写一个函数： write(*,*)f(x) 其中函数 f() 可以做任何该死的事情（包括更改 x），以便注释 write 语句确实会更改程序。实践不佳，但可能。
2）您可能会遇到完全不相关的错误，例如越界访问数组。对代码进行任何类型的更改都可能导致编译器以不同方式对齐内存中的变量，从而导致“隐藏”错误导致问题。
（打开数组边界检查并检查访问未初始化的变量是一个好主意）
1) you could in general write a function: write(*,*)f(x) where function f() does any darn thing (including changing x) so that commenting the write statement does indeed change the program. Poor practice, but possible.
2) you could have a totally unrelated bug such as acessing an array out of bounds. Making any sort of change to the code may cause the compiler to align variables in memory differently, so causeing a 'hidden' bug to cause a problem.
(Turning on array bounds checking, and checking for acessing uninitialised variables is a good idea)