Fil-C Makes setjmp/longjmp and ucontext Memory Safe

Fil-C, the memory-safe C dialect, now supports setjmp/longjmp and the ucontext APIs (setcontext, getcontext, makecontext, swapcontext) without stack corruption or capability violations. The feature landed in release 0.680 and is available when building from source.

The Problem with Context APIs

These APIs are notoriously unsafe because misuse can restore a dangling stack. Common bugs include:

• Calling setjmp or getcontext in a function, then returning — the saved context points to a stack frame that no longer exists.
• Exiting the thread, then trying to restore execution on a freed stack.
• Creating a context with makecontext on a stack, freeing that stack, then swapcontext or setcontext to it.
• Passing the currently executing context as the second argument to swapcontext (swapping to itself).

In standard C ("Yolo-C"), these bugs cause silent stack corruption, hard-to-debug crashes, and potential security exploits. In Fil-C, all such cases produce a panic at the point of misuse.

How Fil-C Implements Memory Safety

Fil-C's approach differs for setjmp/longjmp vs ucontext. For setjmp/longjmp, the key challenge is that setjmp returns twice — once when called, again after longjmp. The act of saving the context means the compiler needs to handle volatile-annotated variables correctly, but Fil-C ensures that restoring a context never accesses freed or invalid memory.

For ucontext, Fil-C manages stacks in a way that either makes the operation legal or panics, because dangling stack frames are simply impossible.

Example: setjmp/longjmp in Fil-C

The following program demonstrates the behavior:

#include <setjmp.h>
#include <stdio.h>

int main(int argc, char** argv) {
    volatile int x = 42;
    jmp_buf jb;
    if (setjmp(jb)) {
        printf("x = %d\n", x);
        return 0;
    }
    x = 666;
    longjmp(jb, 1);
    printf("Should not get here.\n");
    return 1;
}

This prints x = 666 and exits. Without volatile, the compiler may optimize and print 42 instead. Fil-C does not alter optimization semantics but prevents memory corruption regardless.

For Whom?

Developers using ucontext-based coroutines (e.g., Boost fibers) or setjmp/longjmp for exception handling in C programs that want memory safety.