1 .\" Copyright (C) 2016 Michael Kerrisk <mtk.manpages@gmail.com>
3 .\" %%%LICENSE_START(GPLv2+_DOC_FULL)
4 .\" This is free documentation; you can redistribute it and/or
5 .\" modify it under the terms of the GNU General Public License as
6 .\" published by the Free Software Foundation; either version 2 of
7 .\" the License, or (at your option) any later version.
9 .\" The GNU General Public License's references to "object code"
10 .\" and "executables" are to be interpreted as the output of any
11 .\" document formatting or typesetting system, including
12 .\" intermediate and printed output.
14 .\" This manual is distributed in the hope that it will be useful,
15 .\" but WITHOUT ANY WARRANTY; without even the implied warranty of
16 .\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
17 .\" GNU General Public License for more details.
19 .\" You should have received a copy of the GNU General Public
20 .\" License along with this manual; if not, see
21 .\" <http://www.gnu.org/licenses/>.
24 .TH SETJMP 3 2017-03-13 "" "Linux Programmer's Manual"
26 setjmp, sigsetjmp, longjmp, siglongjmp \- performing a nonlocal goto
29 .B #include <setjmp.h>
31 .BI "int setjmp(jmp_buf " env );
32 .BI "int sigsetjmp(sigjmp_buf " env ", int " savesigs );
34 .BI "void longjmp(jmp_buf " env ", int " val );
35 .BI "void siglongjmp(sigjmp_buf " env ", int " val );
39 Feature Test Macro Requirements for glibc (see
40 .BR feature_test_macros (7)):
49 The functions described on this page are used for performing "nonlocal gotos":
50 transferring execution from one function to a predetermined location
54 function dynamically establishes the target to which control
55 will later be transferred, and
57 performs the transfer of execution.
61 function saves various information about the calling environment
62 (typically, the stack pointer, the instruction pointer,
63 possibly the values of other registers and the signal mask)
74 function uses the information saved in
76 to transfer control back to the point where
78 was called and to restore ("rewind") the stack to its state at the time of the
81 In addition, and depending on the implementation (see NOTES),
82 the values of some other registers and the process signal mask
83 may be restored to their state at the time of the
87 Following a successful
89 execution continues as if
91 had returned for a second time.
92 This "fake" return can be distinguished from a true
94 call because the "fake" return returns the value provided in
96 If the programmer mistakenly passes the value 0 in
98 the "fake" return will instead return 1.
100 .SS sigsetjmp() and siglongjmp()
104 also perform nonlocal gotos, but provide predictable handling of
105 the process signal mask.
111 is nonzero, the process's current signal mask is saved in
113 and will be restored if a
115 is later performed with this
121 return 0 when called directly;
122 on the "fake" return that occurs after
126 the nonzero value specified in
134 functions do not return.
136 For an explanation of the terms used in this section, see
142 Interface Attribute Value
146 T} Thread safety MT-Safe
150 T} Thread safety MT-Safe
156 POSIX.1-2001, POSIX.1-2008, C89, C99.
160 POSIX.1-2001, POSIX.1-2008.
162 POSIX does not specify whether
164 will save the signal mask
165 (to be later restored during
167 In System V it will not.
168 In 4.3BSD it will, and there
172 The behavior under Linux depends on the glibc version
173 and the setting of feature test macros.
174 On Linux with glibc versions before 2.19,
176 follows the System V behavior by default,
177 but the BSD behavior is provided if the
179 feature test macro is explicitly defined
180 .\" so that _FAVOR_BSD is triggered
183 .BR _POSIX_C_SOURCE ,
185 .\" .BR _XOPEN_SOURCE_EXTENDED ,
192 exposes only the System V version of
194 Programs that need the BSD semantics should replace calls to
205 can be useful for dealing with errors inside deeply nested function calls
206 or to allow a signal handler to pass control to
207 a specific point in the program,
208 rather than returning to the point where the handler interrupted
211 if you want to portably save and restore signal masks, use
215 See also the discussion of program readability below.
217 The compiler may optimize variables into registers, and
219 may restore the values of other registers in addition to the
220 stack pointer and program counter.
221 Consequently, the values of automatic variables are unspecified
224 if they meet all the following criteria:
226 they are local to the function that made the corresponding
230 their values are changed between the calls to
236 they are not declared as
239 Analogous remarks apply for
242 .SS Nonlocal gotos and program readability
243 While it can be abused,
244 the traditional C "goto" statement at least has the benefit that lexical cues
245 (the goto statement and the target label)
246 allow the programmer to easily perceive the flow of control.
247 Nonlocal gotos provide no such cues: multiple
249 calls might employ the same
251 variable so that the content of the variable may change
252 over the lifetime of the application.
253 Consequently, the programmer may be forced to perform detailed
254 reading of the code to determine the dynamic target of a particular
257 (To make the programmer's life easier, each
259 call should employ a unique
263 Adding further difficulty, the
267 calls may not even be in the same source code module.
269 In summary, nonlocal gotos can make programs harder to understand
270 and maintain, and an alternative should be used if possible.
273 If the function which called
277 is called, the behavior is undefined.
278 Some kind of subtle or unsubtle chaos is sure to result.
280 If, in a multithreaded program, a
284 buffer that was initialized by a call to
286 in a different thread, the behavior is undefined.
288 .\" The following statement appeared in versions up to POSIX.1-2008 TC1,
289 .\" but is set to be removed in POSIX.1-2008 TC2:
291 .\" According to POSIX.1, if a
293 .\" call is performed from a nested signal handler
294 .\" (i.e., from a handler that was invoked in response to a signal that was
295 .\" generated while another signal was already in the process of being
296 .\" handled), the behavior is undefined.
298 POSIX.1-2008 Technical Corrigendum 2 adds
299 .\" http://austingroupbugs.net/view.php?id=516#c1195
303 to the list of async-signal-safe functions.
304 However, the standard recommends avoiding the use of these functions
305 from signal handlers and goes on to point out that
306 if these functions are called from a signal handler that interrupted
307 a call to a non-async-signal-safe function (or some equivalent,
308 such as the steps equivalent to
310 that occur upon a return from the initial call to
312 the behavior is undefined if the program subsequently makes a call to
313 a non-async-signal-safe function.
314 The only way of avoiding undefined behavior is to ensure one of the following:
316 After long jumping from the signal handler,
317 the program does not call any non-async-signal-safe functions
318 and does not return from the initial call to
321 Any signal whose handler performs a long jump must be blocked during
323 call to a non-async-signal-safe function and
324 no non-async-signal-safe functions are called after
325 returning from the initial call to
329 .BR signal-safety (7)