Hacker News Reader

Comment by orra | Hacker News Reader

Panicking (unwinding) across an FFI boundary is very much undefined behaviour. You'd get analogous cross language issues with C++ exceptions. Or mixing GCC ABI unwinding with MSVC ABI unwinding.

Nonetheless, there is a working group, proposing to make it defined under certain circumstances. https://blog.rust-lang.org/inside-rust/2020/02/27/ffi-unwind...

View on HN

But is this undefined behavior in the typical c sense (lol, I see you call function possibly_undefined() I'll just make you a sandwich and clobber all registers instead) - or undefined behavior in the sense that it should crash - but might return?

I’m not sure I'd draw a distinction. People used to say you should initialise your variables in C89 to NULL, so you'd get a crash if you forget to properly set the variable. But enough security bugs have been caused by null pointer dereferences.

In the Rust case, IIRC, Rust annotates functions with the LLVM attribute no_unwind. I'd expect bad things, thanks to optimisation passes, if an unwind were to start. Doubly so if mixing GCC with MSVC ABI.

> is this undefined behavior in the typical c sense (lol, I see you call function possibly_undefined() I'll just make you a sandwich and clobber all registers instead)

Yes.

Thank you for that link, I thought (production build) rust panic was simply a core dump. I didn't realize there was stack unwinding going on.

There are two options at the moment [1]:

  - panic=abort (uncatchable)
  - panic=unwind.

With the latter, you would need a catch_unwind at the FFI boundary.

[1] https://doc.rust-lang.org/cargo/reference/profiles.html#pani...

I see. I would think that for a library, in production, all you'd want for panic was a crash. (I guess this is the abort case).

AAre the panics being discussed for removal in rust tls "soft" errors that should not crash?

There's a categorization here (I don't have access to the triage spreadsheet though):

https://github.com/ctz/rustls/issues/447#issuecomment-820719...

It seems like there's been the most effort on category 4, the ones that can't be reached but can often be proven away with refactoring and typestate. Removing these ensures that the APIs don't expose Result types to callers unnecessarily.

Category 1-3 have different severity, but they are all planned to be folded into Result error values.

Reply on news.ycombinator.com