3 case studies for -Zmiri-tag-raw-pointers #1936
Comments
RalfJung
added
A-aliasing
|
Thanks for sharing! So do all of these involve self-referential structs or 'owning-ref'-style pointers? (I am asking since you mentioned rust-lang/unsafe-code-guidelines#148 and rust-lang/unsafe-code-guidelines#194.) |
|
I don't have any comment on the In the // Shift out the 1 previously placed into the most significant bit of the least
// significant byte. Shift in a low 0 bit to reconstruct the original 2-byte
// aligned pointer.
fn repr_to_ptr(repr: NonZeroU64) -> *const u8 {
// `lea rax, [rdi + rdi]`
(repr.get() << 1) as *const u8
}This looks like an int-to-pointer cast. Or perhaps it even counts as an OOTA pointer? rust-lang/unsafe-code-guidelines#291 doesn't mention doing arithmetic on an integer before converting it back to a pointer. I think the #[macro_export]
macro_rules! make_place {
($name:ident) => {
#[repr(C)]
struct $name<__T> {
out: $crate::__private::Option<__T>,
}
impl<__T> $name<__T> {
fn new(out: &mut $crate::__private::Option<__T>) -> &mut Self {
unsafe { &mut *{ out as *mut $crate::__private::Option<__T> as *mut $name<__T> } }
}
}
};
}But in any case, this |
Ah yes. That is very hard to support with tag-raw-pointers. This seems similar to #1866 (comment) (ferrilab/bitvec#135).
Presumably the arithmetic here results in exactly the same integer value as what was returned by a prior ptr-to-int cast. The problem is more that casting an int to a ptr is inherently a rather cursed operation (for memory that is 'known' to the language -- so this statement excludes accessing non-Rust-managed memory at fixed addresses; that is fine as long as the aliasing rules are otherwise followed). The cast can often be avoided by using something like this, but it can require significant refactoring: // Converts 'addr' to a pointer using the provenance of 'prov'.
fn int_to_ptr_with_provenance<T>(addr: usize, prov: *const T) -> *const T {
// Nowhere in this function do we cast an integer to a pointer!
let ptr = prov.cast::<u8>();
ptr.wrapping_add(addr.wrapping_sub(ptr as usize)).cast()
}In this case it looks like |
|
|
(What does OOTA stand for?) |
Out Of Thin Air: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1217r0.html |
|
Just a minor update: It looks like in the meantime @dtolnay patched So I guess whether or not you say
I do indeed struggle to resist this kind of challenge over the long term :p |
|
PRs to semver: dtolnay/semver#273 and syn: dtolnay/syn#1166 are now merged. I think we could close this now? |
|
Looks like it. Thanks a ton @saethlin :) |
Following @saethlin's and @5225225's PRs dtolnay/ryu#37 and dtolnay/ryu#38, I've been trying
-Zmiri-tag-raw-pointerson some of my repos containing unsafe code. So far the findings mostly line up with my expectations — I just had to fix a few easy cases similar to the PR above (array.get_unchecked(i)⟶array.as_ptr().offset(i)).I found 3 cases of more complicated data structures that I would love to get working with
-Zmiri-tag-raw-pointers. I am opening this issue not primarily because I want someone to come fix my broken code, but in case these are helpful real-world data structures to inform the implementation ofmiri-tag-raw-pointersor the resolution of rust-lang/unsafe-code-guidelines#148 and rust-lang/unsafe-code-guidelines#194, which looked the most relevant to me. Please go ahead and close if you are chock full of controvertible code already and these are not going to be useful.https://github.com/dtolnay/syn
TokenBufferMIRIFLAGS=-Zmiri-tag-raw-pointers cargo miri test --all-features --test test_itemhttps://github.com/dtolnay/semver
IdentifierMIRIFLAGS=-Zmiri-tag-raw-pointers cargo miri test --test test_identifierhttps://github.com/dtolnay/miniserde
Deserializercargo miri test --test test_deriveThe text was updated successfully, but these errors were encountered: