Why is longjmp unsafe with automatic variables?

A strong answer

A strong candidate frames Why is longjmp unsafe with automatic variables? around the exact memory layout, compiler semantics, and hardware execution model covered in Historical & Standard Primitives: setjmp/longjmp, sigaltstack, and ucontext_t. Explain that automatic variables modified between setjmp and longjmp become indeterminate unless declared volatile.

Before writing custom x86-64 assembly to pivot stacks, developers often look for existing standard library mechanisms to switch execution contexts.

The C standard library and POSIX specifications provide three historical facilities:

1. setjmp and longjmp: Standard C non-local jumps across nested function calls.
2. ucontext_t (getcontext, makecontext, swapcontext): The System V / POSIX user-space context-switching API.
3. sigaltstack: The POSIX alternate signal execution stack facility.

In a production interview, always connect the specification rule to its concrete runtime consequence: state what lives on the stack versus the heap or static storage segment, how the compiler or operating system validates alignments, lifetimes, and error codes, and what happens under adversarial or boundary inputs (such as zero-length buffers, integer overflow, concurrent mutation, or partial I/O). Backing your explanation with a small trace of register/memory state transitions immediately separates senior systems engineers from candidates who only memorized syntax.

What the interviewer is listening for

• Mastery of core invariant: Deconstruct jmp_buf internals and non-local jump mechanics in setjmp and longjmp.
• Mastery of core invariant: Identify why longjmp across independent stack boundaries causes undefined behavior.
• Mastery of core invariant: Measure the kernel syscall overhead of signal mask preservation in swapcontext.
• Hardware and ABI awareness: Explaining how sizes, alignments, calling conventions, or kernel boundaries behave on real 64-bit targets rather than relying on implementation-defined assumptions.
• Defensive engineering: Naming the exact compiler flags (-Wall -Wextra -Werror), static analyzers, or runtime sanitizers (-fsanitize=address,undefined,thread) that verify correctness in CI.

Common mistakes

• Explaining only surface syntax without tracing the underlying memory addresses, ownership lifetime, or kernel/user-space state transitions.
• Assuming undefined behavior (such as signed overflow, uninitialized reads, strict-aliasing violations, or dangling pointers) will "just work" because it passed an unoptimized -O0 debug build.
• Ignoring return codes, partial reads/writes, alignment padding, or cleanup paths when an allocation or syscall fails midway through a function.