I presume from the text above that there's an explicit panic handler, so, no, a panic won't cause "a similar result like C", it'll unwind, potentially causing local issues (e.g. it may leak resources which were in the process of being properly dropped when we panicked) and then the Elixir gets control.
If the code does something unsound in an unsafe block then yes, you get to keep both halves like in C. For example if you've decided to unsafely index arbitrarily far into a small array, this will blow up just the same as x[n] in C would. But, why would you do that?
The whole point of explicit unsafe rust is making this type of thing have to be written on purpose. You can't accidentally write unsafe code. And in case you accidentally write unsound code in your explicit unsafe code, you know exactly where to look.
While I agree in principle, the fallacy from security point of view, is assuming it was the same person, or that the error happened in unsafe code block and not elsewhere, caused by wrong invariants.
Hence coding in a safer language by itself isn't a guarantee, care must still be taken.
> that the error happened in unsafe code block and not elsewhere
Remember Rust's Safety Culture, the big C word I mention over and over here and elsewhere that we run into each other? Although the Rust compiler doesn't get to have an opinion about this, Rust's culture does, and Rust says no, the error is in your unsafe block.
Suppose I write a function which takes six 8-bit unsigned integers A, B, C, D, E and F, adds them together and then indexes into an array I own which is 512 entries long. Clearly if you give me most possible values of A through F this is a bounds miss.
If I write this function in safe Rust, it panics when you do that. The bug is in my code, that's where the panic happens.
If I write it in C, it blows up when you do that, but, and here's the crucial part, maybe I say "Idiot, the documentation clearly says in paragraph six see value normality subsection B4, and in B4 I wrote that none of A through F should have values such that when added they sum to 512 or more, thus it's your fault.
If I write it in unsafe Rust then culturally I have two clear choices. One of them is like the C. I write my very extensive documentation and I mark my function unsafe which indicates that callers need to read and understand the documentation to ensure they obey all pre-conditions. Their code will also be unsafe because they can't call my unsafe function without that, reminding them of their responsibility.
The other choice, which is more usual, is to safely encapsulate the feature. I can optionally write extensive documentation, but regardless I must ensure the function cannot cause unsafety even if used by a malicious idiot.
Because of these two options, the problem is always the unsafe code. Maybe it's my unsafe code (I did a bad job either obeying or specifying the preconditions) or maybe it's your unsafe code (you didn't obey my preconditions) but either way it's never the safe code.
Rust's compiler can't promise that but Rust's culture can.
If the code does something unsound in an unsafe block then yes, you get to keep both halves like in C. For example if you've decided to unsafely index arbitrarily far into a small array, this will blow up just the same as x[n] in C would. But, why would you do that?