You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
add checks to the transmute intrinsic to only allow "safe" transmutes #33
This is actually really common (e.g. std::ptr::null() does this).
&T -> *const T (cast/coercion) *const T -> &T (should be a deref)
I agree but this is out of scope of Miri. rustc itself should lint these, IMHO. (Normally I would say clippy, but I think these are important enough for rustc.)
Transmuting a struct with integer at some place to a struct with pointer at that place should be a error.
that means that 0 as *const i32 should be an error, too, since the equivalent transmute<usize, *const i32>(0) would be an error. We'll catch such errors at the use site, if they are errors.
Ignore that. We should definitely error at transmutes, but allow pointer casts until dereferenced
This discussion is going out of bounds in terms of what makes sense to implement inside of Miri. Miri already handles when you do invalid transmutes and then do something that depends on the result being valid (like matching over an enum), it just doesn't error out at transmute time.
Like I said before, this is maybe something that could be brought up as a lint for rustc, but it's not actionable for Miri.
When is a transmute ever UB just by itself? The UB generally comes from the invalid value being used later (and it might not be).
Additionally, it doesn't make sense to special-case transmute. The same effects come from derefing pointers (which might have been casted) and possibly other means. In all these cases Miri is already set up to deal with invalid values that might arise.
Activity
solson commentedon Jun 21, 2016
This is actually really common (e.g.
std::ptr::null()does this).I agree but this is out of scope of Miri. rustc itself should lint these, IMHO. (Normally I would say clippy, but I think these are important enough for rustc.)
oli-obk commentedon Jun 21, 2016
std::ptr::nulluses a castsolson commentedon Jun 21, 2016
@oli-obk Oops, sorry, somehow I misunderstood what you meant even though it was clear. I should have been sleeping rather than replying. :)
Yeah, those transmutes should be linted against, too, ideally by rustc.
cramertj commentedon Jan 25, 2017
| 32-bit values that aren't valid unicode indices casted to char
Shouldn't they be using
std::char::from_u32orstd::char::from_u32_unchecked?bjorn3 commentedon Jan 25, 2017
Transmuting a struct with integer at some place to a struct with pointer at that place should be a error.
oli-obk commentedon Jan 25, 2017
that means that0 as *const i32should be an error, too, since the equivalenttransmute<usize, *const i32>(0)would be an error. We'll catch such errors at the use site, if they are errors.Ignore that. We should definitely error at transmutes, but allow pointer casts until dereferenced
cramertj commentedon Jan 27, 2017
Not sure how hard it would be to check this, but it should also be an error to transmute to an enum with an invalid discriminant.
solson commentedon Jan 28, 2017
This discussion is going out of bounds in terms of what makes sense to implement inside of Miri. Miri already handles when you do invalid transmutes and then do something that depends on the result being valid (like matching over an enum), it just doesn't error out at transmute time.
Like I said before, this is maybe something that could be brought up as a lint for rustc, but it's not actionable for Miri.
oli-obk commentedon Jan 28, 2017
Miri can detect transmutes that are UB because of the value. Everything that is UB because of the types should be a lint.
solson commentedon Jan 28, 2017
When is a transmute ever UB just by itself? The UB generally comes from the invalid value being used later (and it might not be).
Additionally, it doesn't make sense to special-case transmute. The same effects come from derefing pointers (which might have been casted) and possibly other means. In all these cases Miri is already set up to deal with invalid values that might arise.
oli-obk commentedon Jan 28, 2017
right. it would probably be better to include a full tracing mode instead of doing something like this.
Merge pull request rust-lang#33 from bluss/box-slice
Auto merge of #118488 - andjo403:remove_deadlock, r=SparrowLii