LONGJMP(3P)

💖 LONGJMP(3P) — bestie edition 💖

okay so before we even get into it — hi, welcome, this is the POSIX Programmer's Manual page for longjmp, and I need you to know something first 🫶

---

🌸 PROLOG 🌸

This manual page is part of the POSIX Programmer's Manual. The Linux implementation of this interface may differ — so if you're on Linux, go consult the corresponding Linux manual page for the deets on Linux behavior. Or, plot twist, the interface might not even be implemented on Linux at all 💀. Yeah. We love portability.

---

✨ NAME ✨

longjmp — non-local goto 💫

---

🎀 SYNOPSIS 🎀

#include <setjmp.h>

void longjmp(jmp_buf env, int val);

look at her. so simple. so powerful. so dangerous 😌

---

💅 DESCRIPTION 💅

So here's the tea: everything described on this reference page is aligned with the ISO C standard. If there's ever a conflict between what's written here and the ISO C standard — that was NOT intentional, okay? This volume of POSIX.1‐2017 defers to the ISO C standard. Periodt.

The longjmp() function shall restore the environment saved by the most recent invocation of setjmp() in the same process, with the corresponding jmp_buf argument.

Now. The way that this can go horribly wrong 🚨 — the behavior is undefined if any of these apply:

• The most recent invocation of setjmp() with the corresponding jmp_buf occurred in another thread
• There is no such invocation at all
• The function containing the invocation of setjmp() has terminated execution in the interim
• The invocation of setjmp() was within the scope of an identifier with variably modified type, and execution has left that scope in the interim

Also, and this is genuinely unhinged of the standard, it is unspecified whether longjmp() restores the signal mask, leaves the signal mask unchanged, or restores it to its value at the time setjmp() was called. Like. Pick a lane bestie 😭

All accessible objects have values, and all other components of the abstract machine have state (for example, floating-point status flags and open files), as of the time longjmp() was called — except that the values of objects of automatic storage duration are unspecified if they meet all of the following conditions:

• They are local to the function containing the corresponding setjmp() invocation.
• They do not have volatile-qualified type.
• They are changed between the setjmp() invocation and longjmp() call.

(so if you needed a reason to slap volatile on stuff, here it is 🍓)

Although longjmp() is an async-signal-safe function, if it's invoked from a signal handler which interrupted a non-async-signal-safe function or equivalent (such as the processing equivalent to exit() performed after a return from the initial call to main()), then the behavior of any subsequent call to a non-async-signal-safe function or equivalent is undefined. No cap. Undefined.

And finally: the effect of a call to longjmp() where initialization of the jmp_buf structure was not performed in the calling thread is undefined. 💀

---

⭐ RETURN VALUE ⭐

After longjmp() is completed, program execution continues as if the corresponding invocation of setjmp() had just returned the value specified by val.

But plot twist, bestie — longjmp() shall not cause setjmp() to return 0. If val is 0, then setjmp() shall return 1. That's just how it is, iconic behavior honestly 👑

---

🙈 ERRORS 🙈

No errors are defined.

The following sections are informative. (translation: the real ones are done, everything below is bonus content 🎁)

---

🌈 EXAMPLES 🌈

None.

yeah. none. moving on 😭

---

🦋 APPLICATION USAGE 🦋

If your app's behavior depends on the value of the signal mask, you should not use longjmp() and setjmp() — because their effect on the signal mask is unspecified. Instead use siglongjmp() and sigsetjmp(), which can save and restore the signal mask under application control. slay 💅

It is recommended that applications do not call longjmp() or siglongjmp() from signal handlers. To avoid undefined behavior when calling these functions from a signal handler, the application needs to ensure one of the following two things:

1. After the call to longjmp() or siglongjmp() the process only calls async-signal-safe functions and does not return from the initial call to main().
2. Any signal whose handler calls longjmp() or siglongjmp() is blocked during every call to a non-async-signal-safe function, and no such calls are made after returning from the initial call to main().

pick your fighter, fr fr 🥊

---

🧚 RATIONALE 🧚

None.

---

💜 FUTURE DIRECTIONS 💜

None.

---

👑 SEE ALSO 👑

• setjmp()
• sigaction()
• siglongjmp()
• sigsetjmp()

The Base Definitions volume of POSIX.1‐2017, <setjmp.h>

---

📜 COPYRIGHT 📜

Portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1-2017, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of Electrical and Electronics Engineers, Inc and The Open Group.

In the event of any discrepancy between this version and the original IEEE and The Open Group Standard, the original IEEE and The Open Group Standard is the referee document. The original Standard can be obtained online at http://www.opengroup.org/unix/online.html .

Any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. To report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .

---

and that's the whole page bestie, mwah 💋 this came to you from IEEE/The Open Group, 2017, and the page you just read is LONGJMP(3P) 💖✨🎀 go forth and do not longjmp() out of a signal handler, i am literally begging 🫶