-
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
offset_from "same allocation" check is confused by int-to-ptr casts #3767
Comments
This is actually what caught me off guard... because there are no different allocations (in this context). The nd => {
// To get rid of some bounds checks (see `position`), we use ptr_sub instead of
// offset_from (Tested by `codegen/slice-position-bounds-check`.)
// SAFETY: by the type invariant pointers are aligned and `start <= end`
unsafe { end.sub_ptr($self.ptr) }
}, and that's where the error seems to originate from (which leads to the intrinsic I'll try and report back if I'm able to repro it. |
I have a reproducer: fn main() {
let arr = [0; 5];
let begin = arr.as_ptr();
let end = begin.wrapping_add(arr.len());
let end_roundtrip = end as usize as *const i32;
unsafe { end_roundtrip.offset_from(begin) };
} |
@ohsayan yeah you were right, this is indeed a false positive. Thanks for reporting! (That said, Tree Borrows also doesn't support int2ptr cast, but what will almost certainly happen is that it accepts too many programs, not that it gives unexpected errors. Still, in the status quo, the combination of permissive provenance and Tree Borrows is not great as Tree Borrows will just allow any access with a pointer created by int2ptr casts, and also ignore those accesses for the purpose of other pointers being unique/read-only.) |
Rollup merge of rust-lang#128277 - RalfJung:offset_from_wildcard, r=oli-obk miri: fix offset_from behavior on wildcard pointers offset_from wouldn't behave correctly when the "end" pointer was a wildcard pointer (result of an int2ptr cast) just at the end of the allocation. Fix that by expressing the "same allocation" check in terms of two `check_ptr_access_signed` instead of something specific to offset_from, which is both more canonical and works better with wildcard pointers. The second commit just improves diagnostics: I wanted the "pointer is dangling (has no provenance)" message to say how many bytes of memory it expected to see (since if it were 0 bytes, this would actually be legal, so it's good to tell the user that it's not 0 bytes). And then I was annoying that the error looks so different for when you deref a dangling pointer vs an out-of-bounds pointer so I made them more similar. Fixes rust-lang/miri#3767
miri: fix offset_from behavior on wildcard pointers offset_from wouldn't behave correctly when the "end" pointer was a wildcard pointer (result of an int2ptr cast) just at the end of the allocation. Fix that by expressing the "same allocation" check in terms of two `check_ptr_access_signed` instead of something specific to offset_from, which is both more canonical and works better with wildcard pointers. The second commit just improves diagnostics: I wanted the "pointer is dangling (has no provenance)" message to say how many bytes of memory it expected to see (since if it were 0 bytes, this would actually be legal, so it's good to tell the user that it's not 0 bytes). And then I was annoying that the error looks so different for when you deref a dangling pointer vs an out-of-bounds pointer so I made them more similar. Fixes #3767
This code fails with
-Zmiri-disable-stacked-borrows
, but interestingly passes with SB:gives
I think the "same allocation" check in the offset_from intrinsic doesn't work properly when there are wildcard pointers involved.
The text was updated successfully, but these errors were encountered: