This is a case of undefined behavior around unwinding that will not be fixed by the stabilization of the "C-unwind" ABI.
Suppose there exists a C++ library with this function:
void cpp_unwind() {
throw "gotcha";
}
If this function is compiled as part of a crate with panic=unwind:
extern "C-unwind" {
cpp_unwind()
}
pub fn unwinds() { unsafe { cpp_unwind() } }
...and then called from a crate compiled with panic=abort, the behavior is undefined, because the calling function will be compiled with the assumption that unwinding is impossible.
Note:
- If
cpp_unwind is declared with extern "C", the behavior will be well-defined: the runtime will abort even if panic=unwind is used.
- Cargo does not support mixing panic modes like this, so this situation is only possible by invoking
rustc directly (or via a different build system).
- The unwind must originate outside of Rust, because only one
panic!() implementation will be linked in the final binary, so using panic=abort will prevent panic!() from unwinding the stack in the first place.
This is a case of undefined behavior around unwinding that will not be fixed by the stabilization of the
"C-unwind"ABI.Suppose there exists a C++ library with this function:
If this function is compiled as part of a crate with
panic=unwind:...and then called from a crate compiled with
panic=abort, the behavior is undefined, because the calling function will be compiled with the assumption that unwinding is impossible.Note:
cpp_unwindis declared withextern "C", the behavior will be well-defined: the runtime will abort even ifpanic=unwindis used.rustcdirectly (or via a different build system).panic!()implementation will be linked in the final binary, so usingpanic=abortwill preventpanic!()from unwinding the stack in the first place.