longjmp稳定吗？--是的！

因为这两个函数是C库函数，对他的稳定性产生怀疑似乎没有来由。但是先请看一段代码：

#include <stdio.h> #include <stdlib.h> #include <setjmp.h> static jmp_buf jmpbuf_1; int g_a = 0; void test(int index, int *local_val) { g_a = 1111; *local_val = 2222; longjmp(jmpbuf_1,index); } int main(int argc, char *argv[]) { int ret = 0, index = 0; int l_a=1; if(argc!=2) index = 1; else { index = atoi(argv[1]); if(index==0 || index>2) index = 1; } ret = setjmp(jmpbuf_1); if(ret == 0) { printf("Orig setjmp/n"); } else if(ret == 1) { printf("Return From longjmp 1/n"); printf("Global_a: %d/n", g_a); printf("Local_a: %d/n", l_a); return 0; } else if(ret == 2) { printf("Return From longjmp 2/n"); printf("Global_a: %d/n", g_a); printf("Local_a: %d/n", l_a); return 0; } test(index, &l_a); return 0; }

 

这段代码来自互联网，据作者在unix/linux系统下运行的结果据说是这样的：

wangyao@wangyao-laptop:~/Test/sys$ gcc longjmp.c -O2 wangyao@wangyao-laptop:~/Test/sys$ ./a.out 1 Orig setjmp Return From longjmp 1 Global_a: 1111 Local_a: 1 wangyao@wangyao-laptop:~/Test/sys$ ./a.out 2 Orig setjmp Return From longjmp 2 Global_a: 1111 Local_a: 1 wangyao@wangyao-laptop:~/Test/sys$ gcc longjmp.c wangyao@wangyao-laptop:~/Test/sys$ ./a.out 1 Orig setjmp Return From longjmp 1 Global_a: 1111 Local_a: 2222 wangyao@wangyao-laptop:~/Test/sys$ ./a.out 2 Orig setjmp Return From longjmp 2 Global_a: 1111 Local_a: 2222

 

跳转返回后程序的运行结果在不同的编译优化选项下发生的不同。

而且作者引用了unix系统下对longjmp函数的注释：

man 3 longjmp中提到： The values of automatic variables are unspecified after a call to longjmp() if they meet all the following criteria: · they are local to the function that made the corresponding setjmp(3) call; · their values are changed between the calls to setjmp(3) and longjmp(); and · they are not declared as volatile.

似乎这已经意味着longjmp是一个有缺陷的系统了。不是吗？

 

因为工作需要，我跟踪了setjmp,和longjmp的汇编代码，对于堆栈的复原来说，这个跳转机制的实现没有问题。但是对于寄存器的使用，看起来似乎存在疑点——它仅仅保护了有限几个寄存器。那么，其他的那些寄存器似乎意味着在跳转前后是处于一个不可知的状态。所以，

这也从某些方面解释了上面那个测试程序的调用结果。事实上，上述程序的结果可能会显得更加异常。local_variable的打印结果可能即不等于init值，也不等于它在子函数中被改写的值。

 

不过且慢，根据C编译器关于函数调用的规范（我参照的是TMS320C6000系列DSP的C编译器），对于那些setjmp, longjmp没有保护的寄存器，在进行函数调用时，实际上是由编译器自动生成保护代码的。即如果一个寄存器变量在一个函数调用之后还要使用，那么调用子函数之前，C编译器会自动生成入栈的代码，待子函数退出后，父函数会进行出栈操作。longjmp返回setjmp所在函数时，实际上与setjmp()函数首次执行后的操作是完全一样的——即会有未保护寄存器的出栈操作。所以，从这个角度看上面的那段测试代码，就无法解释了。唯一的可能性是：编译器存在bug. 

 

期待你们的意见。。。

 

Dec22,2010 反复用VS2005 和 TMS320C6000的C编译器 对上面那段代码编译，测试结果。结果是稳定的。没有出现随着编译开关的不同，结果出现不同的情形出现。现在正在尝试下载更多的C编译器进行测试。