-
Notifications
You must be signed in to change notification settings - Fork 349
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Detect UB due to unwinding past extern "C"
functions
#1740
Comments
Testcase that should be detected as UB my Miri: #![feature(unwind_attributes)]
#[unwind(allowed)]
extern "C" fn unwind() {
panic!();
}
fn main() {
std::panic::catch_unwind(|| unwind()).unwrap_err();
} |
|
Yes, But that has no effect on UB, I presume? The RFC does not say that these attributes change the fact that unwinding past an |
I would assume that |
That would make sense... I was wondering what the point of that attribute is. "Letting one cause UB" doesn't sound very convincing except when it comes to crafting Miri testcases. ;) |
This would still be UB though I think: #![feature(c_unwind)]
extern "C-unwind" fn unwind() {
panic!();
}
fn main() {
let unwind: extern "C-unwind" fn() = unwind;
let unwind: extern "C" fn() = unsafe { std::mem::transmute(unwind) };
std::panic::catch_unwind(|| unwind()).unwrap_err();
} The caller uses a non-unwinding ABI so it might not have cleanup blocks; unwinding anyway is thus UB. |
Yes, the MIR of the caller would omit cleanup blocks. |
ensure we catch incorrectly unwinding calls Fixes #1740
I since then learned that indeed it does affect UB; |
Even with rust-lang/rust#76570, I think it is possible to unwind past an
extern "C"
function by setting an#[unwind]
attribute, and that is UB. We should make sure Miri detects that UB.The text was updated successfully, but these errors were encountered: