非本地跳转之setjmp与longjmp

非本地跳转(unlocal jump)是与本地跳转相对应的一个概念。

本地跳转主要指的是类似于goto语句的一系列应用，当设置了标志之后，可以跳到所在函数内部的标号上。然而，本地跳转不能将控制权转移到所在程序的任意地点，不能跨越函数，因此也就有了非本地跳转。

C语言里面提供了setjmp和longjmp函数来进行跨越函数之间的控制权的跳转，从而称之为非本地跳转。

#include <setjmp.h>
int setjmp(jmp_buf env);

该函数主要用来保存当前执行状态，作为后续跳转的目标。调用时，当前状态会被存放在env指向的结构中，env将被 long_jmp 操作作为参数，以返回调用点，跳转的结果看起来就好像刚从setjmp返回一样。

需要注意的是，第一次调用setjmp的时候返回值为0；而从long_jmp操作返回时，返回值是非0的，数值与longjmp传入的参数value有关。通过判断setjmp的返回值，就可以判断当前执行状态。

#include<setjmp.h>
void long_jmp(jmp_buf env, int value);

该函数用来恢复env中保存的执行状态，另一参数value用来传递返回值给跳转目标。如果value值为0，则跳转后返回setjmp处的值为1；否则，返回setjmp处的值为value。

因此，整个非本地跳转的执行过程是：首先，在程序中调用setjmp进行当前运行栈环境的保存，接着在程序的其它地方调用longjmp进行跳转，跳转回的位置就是该setjmp的位置。

这其中需要注意的是：jmp_buf类型的变量env，因为该变量保存的是当前执行位置的运行栈环境；因此如果需要还能跳转到这个位置，那么longjmp必须能调用到这个env变量，因此这个变量一般为全局的。

接下来，简单的介绍一下运行栈的概念。

运行栈

简单的来说，程序运行的时候如果一个函数Fa内部调用了另一个函数Fb，那么当Fb执行完了之后，控制权如何返回给Fa，并继续执行Fa后面的语句呢？这就使用到了运行栈。

简要的说，运行栈里按照函数调用的顺序将一个个函数压入栈中，当一个函数执行结束之后，这个函数的栈帧(stack frame)就会从运行栈中pop出来，并将控制权(PC)转向调用函数(callee)，控制权的记录就在每个函数所对应的的栈帧中。

因此，如果我们有程序段如下：

void Fa()
{
    ...
    Fb();
    ...
}
void Fb()
{
    ...
    Fc();
    ...
}
void Fc()
{
    ...
    //do something here
}

void main()
{
    ...
    Fa();
}

那么，当调用到函数Fc时程序的运行栈大致如下图所示：

当执行完Fc之后就会将Fc的栈帧pop出来，如下图所示：

非本地跳转模拟异常处理机制

当使用非本地跳转时，就不需要一层层的解开程序调用栈，而是直接将控制流转移到对应的位置。

在最初，还没有实现异常处理机制的时候，有的时候会用非本地跳转来模拟异常处理机制，大致思路如下：

#define myTry if(setjmp(env) == 0){

#define myCatch(err) }else if(err != NULL){ \
                                   //TO DO SOMETHING HERE
                                            \
                               }

#define myThrow(err) longjmp(env, err.ToInteger())

在myTry处设置setjmp，并保存当前的程序运行栈到env中，当程序中某个函数throw出一个异常时，就使用longjmp进行跳转。此时，程序又回到了setjmp处，但是因为返回值已经被设置为err.ToInteger()，因此setjmp的返回值肯定不是0，于是程序就进入到了else if分支，即myCatch语句块中。

但是，使用非本地跳转来模拟异常处理机制时会产生一定的问题，那就是在语句块中定义的局部变量所占的内存并不会被正常的释放，导致内存泄漏。

因为，非本地跳转在发生跳转时是直接将程序的控制流转移过去，而不是进行正常的栈退解(stack unwinding)操作，因此并不能识别出其中的变量并进行析构，不过现在的一些编译器已经实现了相应的功能，因编译器而异。