关于“setjmp（）”的问题 [英] question about "setjmp()"
问题描述
大家好，
我在最近的一个程序中使用了setjmp（）（它没有完成，所以
我没有机会测试它）。我和其他一些同事一样，并不是非常擅长编码。他们（我的同事）说（用
激烈的ardor;））使用setjmp（）在函数C中使用了从函数调用的
; B"从函数A调用的那个从主要（）调用的
将导致堆栈中的破坏。并且它有意义，因为longjmp（）函数/宏无法知道
堆栈有多高，以便弹出多余的元素
为了渲染它，就像setjmp（）函数第一次设置
" jmpbuf"环境。但是，如果存在
，则setjmp（）/ longjmp（）函数对将不存在。
所以，是setjmp（）/ longjmp（）作为非本地goto可靠，或者它会不会导致堆栈溢出或其他一些问题？
PS我只使用setjmp（）/ longjmp（）进行错误处理。
问候，
-Roger
Hello all,
I used setjmp() in a recent of program of mine (it is not completed, so
I have not the chance to test it out yet). I am not very profocient in
C coding as are some of my co-workers. They (my co-workers) say (with
vehement ardor ;) ) that the usage of setjmp() emplyoyed in function"C"
that was called from function "B" that was called from function "A"
that was called form the main(), will cause havoc in the stack. And it
makes sense, since the longjmp() function/macro has no way of knowing
how high is the stack is, in order to pop out the excess elements in
order to render it as it was when the setjmp() function first set the
"jmpbuf" environment. However, if that were the case the existence of
the setjmp()/longjmp() function pair will not exist.
So, is setjmp()/longjmp() reliable as a "non-local goto", or will it
eventually cause a stack overflow or some other problem?
P.S. I am using the setjmp()/longjmp() only for error handling.
Regards,
-Roger
推荐答案
rover8898写道：
rover8898 wrote:
大家好，
我在最近的一个程序中使用了setjmp（）（它没有完成，所以
我还没有机会测试它）。我和其他一些同事一样，并不是非常擅长编码。他们（我的同事）说（用
Hello all,
I used setjmp() in a recent of program of mine (it is not completed, so
I have not the chance to test it out yet). I am not very profocient in
C coding as are some of my co-workers. They (my co-workers) say (with
如果你不精通C那么我绝对不建议玩
使用任何* jmp（）函数。即使你确实熟练，我也会找到另一种方法。我个人从不使用它们，但这并不一定是$ />
表示他们没用。
If you''re not proficient with C then I definitely do not recommend playing
around with any *jmp() function. Even when you do become proficient, I''d find
another method. I personally never use them, but that doesn''t necessarily
mean they are useless.
很高兴你有同事来帮助你。他们似乎很好
足够知道如果
你已经嵌套了33级并且想要跳到邮件程序那么需要一点摆弄。
但是setjmp / longjmp管理得很好。基本的rigamarole是
setjmp（）将所有CPU寄存器（包括堆栈指针）保存在其保存区域参数的
中。然后longjmp （）大多只是恢复那些
寄存器值，包括旧的程序计数器。快速和光滑
并且应该使用但是在某些情况下，它几乎不可避免地会花费b / b $
在更精致的语言中，像旧的Pascal一样，没有限制
goto'，编译器生成正确的代码来执行
进程间跳转。作为一个附带好处，编译器知道什么
文件是所有中间级别的本地文件，并关闭它们。可怜
setjmp（）没有任何方法可以知道哪些文件是打开的，所以你要
必须编写自己的代码来清理任何打开的文件。 br />
It''s nice you have coworkers to help you. And they seem to be well
enough informed to realize there is a bit of fiddling required if
you''re nested 33 levels deep and want to jump out to the mail program.
But setjmp/longjmp manage this just fine. The basic rigamarole is
setjmp() saves all the CPU registers, including the stack pointer, in
its save area parameter. Then longjmp() mostly just restores those
register values, including the old program counter. Quick and slick
and should probably be used sparingly. But in some cases it''s almost
unavoidable.
In more refined languages, like old Pascal, there is no restriction on
goto''s, and the compiler generates the right code to do the
inter-procedure jumps. And as a side-benefit, the compiler knows what
files are local to all the intermediate levels, and closes them. Poor
setjmp() doesnt have any way of knowing what files are open, so you''ll
have to write your own code to clean up any open files.
Ancient_Hacker写道：
Ancient_Hacker wrote:
很高兴有同事帮助你。并且它们似乎很好
足够了解如果
嵌套了33级深度且想要跳到邮件中需要一点摆弄程序。
但是setjmp / longjmp管理得很好。基本的rigamarole是
setjmp（）将所有CPU寄存器（包括堆栈指针）保存在其保存区域参数的
中。然后longjmp（）大多只是恢复那些
寄存器值，包括旧的程序计数器。快速和光滑
，应该谨慎使用。但在某些情况下，它几乎是不可避免的b $ b。
在更精致的语言中，如旧的Pascal，对
$没有限制。 b $ b goto'，编译器生成正确的代码来执行
进程间跳转。作为一个附带好处，编译器知道什么
文件是所有中间级别的本地文件，并关闭它们。可怜
setjmp（）没有办法知道哪些文件是打开的，所以你要
必须编写自己的代码来清理所有打开的文件。
It''s nice you have coworkers to help you. And they seem to be well
enough informed to realize there is a bit of fiddling required if
you''re nested 33 levels deep and want to jump out to the mail program.
But setjmp/longjmp manage this just fine. The basic rigamarole is
setjmp() saves all the CPU registers, including the stack pointer, in
its save area parameter. Then longjmp() mostly just restores those
register values, including the old program counter. Quick and slick
and should probably be used sparingly. But in some cases it''s almost
unavoidable.
In more refined languages, like old Pascal, there is no restriction on
goto''s, and the compiler generates the right code to do the
inter-procedure jumps. And as a side-benefit, the compiler knows what
files are local to all the intermediate levels, and closes them. Poor
setjmp() doesnt have any way of knowing what files are open, so you''ll
have to write your own code to clean up any open files.
AH触及一个更大问题的一个方面：longjmp（）
只是将所有中间调用级别反弹回到
setjmp（）调用者，没有给跳过的级别任何机会
清理*任何东西* - 他提到打开的文件没有得到
关闭，但是与malloc（）ed内存相同的问题是
没有得到免费（）d，绘制的窗户不会被删除，并且
没有被蹲的小赌注。
简而言之，尽管有长这个词。在名称中，longjmp（）应该
实际上只用于短在一个紧密耦合的集合中跳跃
的函数。 setjmp（）和longjmp（）
之间的函数必须知道它们的不稳定位置，并且必须以
方式编写，不需要清理longjmp（）可能会取消。函数
可以用这种方式编写，并且写得很有用，但是编写它们并且*保护它们以防止未来的变化是不小的。因此
建议：大部分时间避免使用setjmp（）/ longjmp（），当你使用它们时，请使用它们本地。它们不是通用的。
-
Eric Sosman
es ***** @ acm-dot-org.inva 盖子
这篇关于关于“setjmp（）”的问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
