Nah, just nitpicking. Though I guess the point is that AFAIK there's no documentation for all the ways that safe rust code is allowed to segfault; the distinction between a in-rust panic is that a segfault would probably crash beam, whereas an in-rust panic might be recoverable?
> there's no documentation for all the ways that safe rust code is allowed to segfault
I wouldn't say "allowed" to segfault. :P The behavior you're referring to is currently due to a deficiency in LLVM for non-Windows platforms. Here's the bug on the Rust repo tracking it: https://github.com/rust-lang/rust/issues/16012 Its resolution is long-awaited, to say the least, but it requires someone proficient with LLVM to do the legwork...
> an in-rust panic might be recoverable?
Anytime you're writing an interface where code is going to be calling into Rust via C FFI, you ought to be using https://doc.rust-lang.org/std/panic/fn.catch_unwind.html , which is specifically intended to prevent panics from crossing FFI boundaries.
Anytime our guard pages detect a stack overflow, an abort is issued with no chance to unwind. (The segfault bug mentioned above is caused by crafting data on the stack such that you bypass the guard page, which would go from a segfault into an abort in the presence of stack probes.) I did not intend to imply that there was any chance that a stack overflow wouldn't bring down your process, only to clarify Rust's stance on the theoretical memory safety implications. :)
