-
Notifications
You must be signed in to change notification settings - Fork 81
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
Implement FromBytes
and AsBytes
for raw pointers
#170
Comments
Previously, we omitted these impls out of a fear of creating a footgun in which it would be too easy to mistakenly transmute into a type with internal safety invariants. Recently, this omission meant that I was unable to get rid of a number of lines of `unsafe` code in a codebase that used raw pointers, and it made me realize that it is more important to enable this use case than to avoid a theoretical footgun. Closes #170
@djkoloski Given the discussion in rust-lang/unsafe-code-guidelines#401, how would you feel about just implementing |
I would lean towards treating One could imagine a parallel world where raw pointers were The proof burden/overhead of writing The calculus is a bit different here since these are opt-in derivable traits rather than autotraits, but I'd say the same logic still applies. It should be fine to just derive all derivable traits without needing to consider whether |
I was under the impression that transmuting pointers to/from bytes was always sound, and that it was just dereferencing transmuted pointers which was unsound. I think that's maybe correct in practice but not entirely correct in theory? @joshlf Could you point to an example type with pointers that you want to use zerocopy on? I think there is a lot of room for compromise, like a transparent wrapper type or a field attribute with the derive. |
As mentioned in the linked issue, this is basically correct, but even if so, the argument @CAD97 is making is that users might make the mistaken assumption (the docs are not clear on whether this is true or not) that transmuting something If you are okay with a wrapper type, I would suggest an |
So I think I may have jumped the gun on this one. The original impetus for considering adding these impls was that I was doing a pass through Fuchsia's codebase, looking for However, when I went back now to answer your question, I looked through and found precisely two instances of
Now, that's only for For the morbidly curious, here's the full output of Output
|
Follow up: Would it be sound to implement cc @RalfJung since we've been talking about pointer validity and provenance |
I can't think of any reason this would be problematic. I'm not sure if we document that 0 is the null pointer (I'm guessing we do), but it doesn't need to have provenance in any case. |
I assume that, despite fat pointers logically containing a thin pointer and a length, the actual layout/bit representation of fat pointers is not guaranteed by the reference, and so it would not be sound to implement |
Transmuting a (Note that the resulting pointer might be "even less valid than a
Layout of wide pointers is indeed undocumented, they may only be created via |
Leaving a note here: if we implement this Clippy lint, then this may be less dangerous, since our |
Makes progress on #170
Implements `TryFromBytes` and `FromZeros` for `AtomicPtr`; `FromBytes` and `IntoBytes` are blocked by #170. This is adapted from @josephlr's similar implementation in #1092. Fixes #1086 Co-authored-by: Joe Richey <[email protected]>
Implements `TryFromBytes` and `FromZeros` for `AtomicPtr`; `FromBytes` and `IntoBytes` are blocked by #170. This is adapted from @josephlr's similar implementation in #1092. Fixes #1086 Co-authored-by: Joe Richey <[email protected]>
Implements `TryFromBytes` and `FromZeros` for `AtomicPtr`; `FromBytes` and `IntoBytes` are blocked by #170. This is adapted from @josephlr's similar implementation in #1092. Fixes #1086 Co-authored-by: Joe Richey <[email protected]>
Implements `TryFromBytes` and `FromZeros` for `AtomicPtr`; `FromBytes` and `IntoBytes` are blocked by #170. This is adapted from @josephlr's similar implementation in #1092. Fixes #1086 Co-authored-by: Joe Richey <[email protected]>
Implements `TryFromBytes` and `FromZeros` for `AtomicPtr`; `FromBytes` and `IntoBytes` are blocked by #170. This is adapted from @josephlr's similar implementation in #1092. Fixes #1086 Co-authored-by: Joe Richey <[email protected]>
Implements `TryFromBytes` and `FromZeros` for `AtomicPtr`; `FromBytes` and `IntoBytes` are blocked by #170. This is adapted from @josephlr's similar implementation in #1092. Fixes #1086 Co-authored-by: Joe Richey <[email protected]>
Implements `TryFromBytes` and `FromZeros` for `AtomicPtr`; `FromBytes` and `IntoBytes` are blocked by #170. This is adapted from @josephlr's similar implementation in #1092. Fixes #1086 Co-authored-by: Joe Richey <[email protected]>
Implements `TryFromBytes` and `FromZeros` for `AtomicPtr`; `FromBytes` and `IntoBytes` are blocked by #170. This is adapted from @josephlr's similar implementation in #1092. Fixes #1086 Co-authored-by: Joe Richey <[email protected]>
Implements `TryFromBytes` and `FromZeros` for `AtomicPtr`; `FromBytes` and `IntoBytes` are blocked by #170. This is adapted from @josephlr's similar implementation in #1092. Fixes #1086 Co-authored-by: Joe Richey <[email protected]>
Implements `TryFromBytes` and `FromZeros` for `AtomicPtr`; `FromBytes` and `IntoBytes` are blocked by #170. This is adapted from @josephlr's similar implementation in #1092. Fixes #1086 Co-authored-by: Joe Richey <[email protected]>
Implements `TryFromBytes` and `FromZeros` for `AtomicPtr`; `FromBytes` and `IntoBytes` are blocked by #170. This is adapted from @josephlr's similar implementation in #1092. Fixes #1086 Co-authored-by: Joe Richey <[email protected]>
Implements `TryFromBytes` and `FromZeros` for `AtomicPtr`; `FromBytes` and `IntoBytes` are blocked by #170. This is adapted from @josephlr's similar implementation in #1092. Fixes #1086 Co-authored-by: Joe Richey <[email protected]>
Implements `TryFromBytes` and `FromZeros` for `AtomicPtr`; `FromBytes` and `IntoBytes` are blocked by #170. This is adapted from @josephlr's similar implementation in #1092. Fixes #1086 Co-authored-by: Joe Richey <[email protected]>
Implements `TryFromBytes` and `FromZeros` for `AtomicPtr`; `FromBytes` and `IntoBytes` are blocked by #170. This is adapted from @josephlr's similar implementation in #1092. Fixes #1086 Co-authored-by: Joe Richey <[email protected]>
Implements `TryFromBytes` and `FromZeros` for `AtomicPtr`; `FromBytes` and `IntoBytes` are blocked by #170. This is adapted from @josephlr's similar implementation in #1092. Fixes #1086 Co-authored-by: Joe Richey <[email protected]>
Implements `TryFromBytes` and `FromZeros` for `AtomicPtr`; `FromBytes` and `IntoBytes` are blocked by #170. This is adapted from @josephlr's similar implementation in #1092. Fixes #1086 Co-authored-by: Joe Richey <[email protected]>
Implements `TryFromBytes` and `FromZeros` for `AtomicPtr`; `FromBytes` and `IntoBytes` are blocked by #170. This is adapted from @josephlr's similar implementation in #1092. Fixes #1086 Co-authored-by: Joe Richey <[email protected]>
Historically, we've avoided adding these impls for fear that they could present a footgun, making it easier to accidentally transmute into a type, breaking its safety invariants.
Today, I was working on replacing some
unsafe
code in Fuchsia's Starnix project with zerocopy, and ran into some structs for which I can't deriveFromBytes
orAsBytes
because they contain raw pointers. Currently, the lack of impls on raw pointers is entirely preventing thisunsafe
code from being replaced by zerocopy, which feels to me like throwing the baby out with the bathwater. IMO, it's more important to unlock this use case than to avoid a minor and theoretical footgun.Note that, while the layout of raw pointers is well-defined, it's less clear that their bit validity is well-defined.
TODO:
The text was updated successfully, but these errors were encountered: