Skip to content
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

Review documented lifetime requirements for &mut vs *mut rules #309

Open
jsha opened this issue Mar 23, 2023 · 0 comments
Open

Review documented lifetime requirements for &mut vs *mut rules #309

jsha opened this issue Mar 23, 2023 · 0 comments

Comments

@jsha
Copy link
Collaborator

jsha commented Mar 23, 2023

(Copied from #291 (comment))

We arrange for (non-Rust) callers of our function to uphold the safety guarantees by asking them to uphold a few properties:

  • We only hand out pointers to our structs that follow the rules above (aligned, initialized, etc).
  • We document the lifetime requirements of those pointers.
  • We provide *const pointers for things that may have aliases.
  • We expect callers to never cast between types or cast away const.
  • We provide *mut pointers for things that may be mutated. This is actually an area we should tighten up. The rules for what you can do with a *mut pointer are very slightly looser than the rules for what you can do with an &mut reference. For instance, the rules are triggered on dereference of raw pointers, while the rules are triggered on mere existence for references. But because we almost always have to convert a *mut pointer to an &mut reference to call methods, we have to ask our callers to uphold the more stringent &mut rules.

https://doc.rust-lang.org/nomicon/aliasing.html

I believe it's okay for a *mut pointer to coexist with an &mut reference. It's just that an &mut reference can't coexist with an &mut reference. So it's possible our documented lifetime requirements are already fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant