Safely working with libraries that use setjmp/longjmp

[daurnimator]

(as discussed on IRC):

Some C environments/libraries use setjmp+longjmp for control flow. e.g. writing PostgreSQL Extensions or the Lua C API.

A C function longjmp-ing out may result in zig code not being run. This may include defer-d code for cleanup, which will result in various resource leaks or even deadlocks.

Proposed Solution

Functions should gain a may longjmp annotation (possibly with an arbitrary ID?).

• Such a function can only be called from other functions annotated with may longjmp unless a matching setjmp annotation is found.
• A compile error (possibly warning?) is thrown if defer occurs before a may longjmp function call in the same (or child) scope.
  It is fine if the defer block occurs after the call to the may longjmp function, as the longjmp() would already have happened.

[shawnl]

What about setjmp/longjmp in Zig code?

[andrewrk]

The zig language currently has no plan for the spec to include the concept of a function that returns twice. This means that setjmp in Zig is unsound and cannot be used.

[daurnimator]

The zig language currently has no plan for the spec to include the concept of a function that returns twice. This means that setjmp in Zig is unsound and cannot be used.

This issue is not so much about setjmp as longjmp, which is a very common error handling pattern in C libraries (see, Postgres and Lua as linked in original post).

[yrashk]

@daurnimator I wonder if you researched the subject of integrating with setjmp/longjmp-using libraries with Zig any further? My angle of interest is Postgres extensions. In Rust's pgx library they establish an FFI boundary around every call to Postgres to ensure that if they throw an error, it's caught by Rust.