Assertions across FFI boundaries

[ryankurte]

so i'm working on drivers with FFI from rust -> c -> rust to allow iterative upgrading of existing c to rust, and as unwinding doesn't work over FFI boundaries, this results in a lovely SIGSEGV :-/

points in favour of the previously discussed lists of expectations-vs-reality based approach we discussed some time ago, i wonder whether it's reasonable to expand the project to support both with an opt-out feature for panics?

[dbrgn]

Hm, so you're triggering some of the panics from C code in your test suite? Can you elaborate what that use case looks like?

[ryankurte]

so i've got c objects that take function pointers (something like this), that i'm dependency injecting rust functions in place of the C ones, then wrapping the C methods on the object in rust. So when you call a rust function, it calls the c function, which then calls back to the rust functions...

the panics are still triggered in rust, but, once you've passed through the ffi boundary it seems to be vvv sad about it.

[dbrgn]

Yeah, panics across FFI boundaries are not supported.

I guess we could wrap the assertion macros with our own macros, and swap them out in case in case you do FFI? The question is how to handle them instead. Maybe allocate some static memory and write the assertion result to that memory location, so that C code can fetch it?

[ryankurte]

something like that might work? at the time i imagined removing the inline panics and reading/writing to arrays to be finalised from the test code at the end. the advantage is of this approach is that this means you see a whole test with mismatching transactions in it, the disadvantage is that you don't get a backtrace of where the error occured.

[dbrgn]

I'll close this for now, since this seems to be a bit of an edge case. If you can come up with a sufficiently simple implementation to support this, that doesn't add too much maintenance overhead, I'd consider it.