Linux API. Исчерпывающее руководство

Применение функций setjmp() и longjmp() показано в листинге 6.5. Эта программа с помощью предварительного вызова setjmp() устанавливает цель перехода. Дальнейшее использование инструкции switch (на основе значения, возвращаемого setjmp()) позволяет различить первоначальный возврат из функции setjmp() и возврат после longjmp(). Если возвращаемое значение равно 0, значит, только что был сделан первоначальный вызов setjmp() — мы вызываем функцию f1(), которая либо сразу же вызывает longjmp(), либо переходит к вызову f2(), в зависимости от значения argc (то есть количества аргументов командной строки). Если управление перешло в f2(), в ней тут же происходит вызов longjmp(). Вызов функции longjmp() из любой функции возвращает нас назад, к тому месту, из которого была вызвана setjmp(). В двух вызовах longjmp() используются разные аргументы val, поэтому инструкция switch в main() может определить функцию, из которой произошел переход, и вывести на экран соответствующее сообщение.

При запуске программы из листинга 6.5 без каких-либо аргументов командной строки мы увидим следующее:

$ ./longjmp

Вызов f1() после предварительного вызова setjmp()

Мы вернулись назад из f1()

Указание аргумента командной строки приводит к переходу, осуществляемому из f2():

$ ./longjmp x

Вызов f1() после предварительного вызова setjmp()

Мы вернулись назад из f2()

Листинг 6.5. Демонстрирует использование вызовов setjmp() и longjmp()

proc/longjmp.c

#include

#include "tlpi_hdr.h"

static jmp_buf env;

static void

f2(void)

{

longjmp(env, 2);

}

static void

f1(int argc)

{

if (argc == 1)

longjmp(env, 1);

f2();

}

int

main(int argc, char *argv[])

{

switch (setjmp(env)) {

case 0: /* Это возвращение после предварительного вызова setjmp() */

printf("Calling f1() after initial setjmp()\n");

f1(argc); /* Данная программа никогда не выполнит

break из следующей строки…. */

break; /*… но хороший тон обязывает нас его написать.*/

case 1:

printf("We jumped back from f1()\n");

break;

case 2:

printf("We jumped back from f2()\n");

break;

}

exit(EXIT_SUCCESS);

}

proc/longjmp.c

Ограничения, накладываемые на использование setjmp()

В SUSv3 и C99 указывается, что вызов setjmp() может присутствовать только в следующих контекстах:

• в качестве цельного управляющего выражения инструкции выбора или итерации (if, switch, while и т. д.);

• в качестве операнда унарного оператора! (НЕ), где получающееся в результате выражение является цельным управляющим выражением инструкции выбора или итерации;

• в качестве части операции сравнения (==,!=, < и т. д.), где другой операнд является выражением целочисленной константы и получающееся в результате выражение является цельным управляющим выражением инструкции выбора или итерации;

• в качестве обособленного вызова функции, не встроенного в какое-либо более сложное выражение.

Обратите внимание, что в приведенном выше списке отсутствует инструкция присваивания языка C. Инструкция, выраженная в следующей форме, не соответствует стандарту:

s = setjmp(env); /* НЕВЕРНО! */

Эти ограничения наложены из-за того, что реализация setjmp() в качестве обычной функции не может гарантировать достаточный объем информации, позволяющий сохранять значения всех регистров и промежуточных мест в стеке, используемых в охватывающем выражении, чтобы затем они могли быть правильно восстановлены после вызова longjmp(). Поэтому вызов setjmp() допускается только внутри достаточно простых выражений, не требующих промежуточных мест хранения данных.

Неверное применение longjmp()

Если буфер env объявлен глобальным для всех функций (что обычно и делается), это допускает выполнение следующей последовательности.

1. Вызов функции x(), использующей setjmp() для установки цели перехода в глобальной переменной env.

2. Возвращение из функции x().

3. Вызов функции y(), выполняющей longjmp() с использованием env.

Это серьезная ошибка. Нельзя выполнять переход с помощью функции longjmp() в функцию, из которой уже произошел возврат. Что longjmp() пытается сделать со стеком? Она пытается раскрутить назад к фрейму, которого уже нет, что приводит в результате к хаосу. Если повезет, наша программа просто даст сбой. Но в зависимости от состояния стека могут возникать бесконечные циклы вызова-возврата, и программа начнет вести себя так, будто она на самом деле вернула управление из функции, которая на тот момент не выполнялась. (В многопоточной программе подобное неверное действие заключается в вызове longjmp() в другом потоке, отличающемся от того, где был осуществлен вызов setjmp().)

В SUSv3 говорится, что, если longjmp() вызывается из вложенного обработчика сигнала (то есть из обработчика, который вызывается при выполнении другого обработчика сигнала), поведение программы становится неопределенным.

Проблемы, связанные с оптимизирующими компиляторами