-
Notifications
You must be signed in to change notification settings - Fork 109
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
Keep provenance intact by avoiding ptr-int-ptr #185
Conversation
16b6312
to
0546d91
Compare
|
Could you add a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we have that polyfill we might as well use it? :D
…enance This branch merges upstream's `master` branch into PR matklad#185. I need to patch a dependency on `once_cell` that needs at least 1.13.0 to pick up the provenance fix, but you may want to actually merge this into the PR as well.
This adds a Cargo patch for the `once_cell` crate to pick up an upstream branch that fixes an int-to-pointer cast that Miri rejects. The patch can be removed once matklad/once_cell#185 has merged.
This adds a Cargo patch for the `once_cell` crate to pick up an upstream branch that fixes an int-to-pointer cast that Miri rejects. The patch can be removed once matklad/once_cell#185 has merged.
This adds a Cargo patch for the `once_cell` crate to pick up an upstream branch that fixes an int-to-pointer cast that Miri rejects. The patch can be removed once matklad/once_cell#185 has merged.
once_cell is an extremely widely-used crate, so it would be very nice if it conformed to the stricted/simplest/checkable model we have for aliasing in Rust. To do this, we need to avoid creating a pointer from an integer by cast or transmute. Pointers created this way can be valid, but are a nightmare for a checker like Miri. The situation is generally explained by these docs: https://doc.rust-lang.org/nightly/std/ptr/fn.from_exposed_addr.html This implementation is mostly gross because all the APIs that would make this ergonomic are behind #![feature(strict_provenance)]
Is there a reason to be pasting in sptr rather than depending on it? |
I assume it's to avoid having an extra dependency, as |
|
bors r+ I don't think it's worth it to go from 0 deps to >0 deps just for this |
Well, at least this is getting merged. |
Build succeeded: |
Released as https://crates.io/crates/once_cell/1.13.1 |
once_cell
is an extremely widely-used crate, so it would be very nice if it conformed to the stricted/simplest/checkable model we have for aliasing in Rust. To do this, we need to avoid creating a pointer from an integer by cast or transmute. Pointers created this way can be valid, but are a nightmare for a checker like Miri. The situation is generally explained by these docs: https://doc.rust-lang.org/nightly/std/ptr/fn.from_exposed_addr.htmlThis implementation is mostly gross because all the APIs that would make this ergonomic are behind
#![feature(strict_provenance)]
. (in particular, it would be great to havemap_addr
here)