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

Make unsafe pointers always non-null #2971

Closed
jruderman opened this issue Jul 20, 2012 · 5 comments
Closed

Make unsafe pointers always non-null #2971

jruderman opened this issue Jul 20, 2012 · 5 comments

Comments

@jruderman
Copy link
Contributor

"I am managing the lifetime of this pointer myself" and "I might have null instead of a pointer" should be orthogonal concepts.

I suggest:

This would help clarify code that uses unsafe pointers.

@pcwalton
Copy link
Contributor

Note that you could still of course write ptr::null in unsafe code by reinterpret_casting between numbers and pointers.

@jruderman
Copy link
Contributor Author

When would you want to do that instead of writing option(none)?

@pcwalton
Copy link
Contributor

No reason, I'm just noting we can't prevent folks from creating null
pointers in unsafe code.
On Jul 19, 2012 11:14 PM, "Jesse Ruderman" <
reply@reply.github.com>
wrote:

When would you want to do that instead of writing option(none)?


Reply to this email directly or view it on GitHub:
#2971 (comment)

@nikomatsakis
Copy link
Contributor

I don't know how this would work for C functions that return pointers. It seems like the null-ness would be "documented" in the return type. This cannot be automatically determined by bindgen, however, and so we would end up with a lot of option types, making code that interfaces with C more annoying to write. Removing those option types would give people the illusion of safety (I can't get null pointer derefs! Even in unsafe code!) in trade for convenience, always a bad tradeoff as people tend to favor convenience. For this reason, I am opposed though I like the idea in spirit. Going to close, feel free to re-open if you feel my argument is unpersuasive.

@Diggsey
Copy link
Contributor

Diggsey commented Oct 27, 2014

It would be possible to avoid that by having the compiler force the use of "Option<T*>" instead of just "T*" when binding to C code. It's more verbose, but:

  • It avoids confusion about whether the value can be null
  • It's consistent with the other pointer types
  • It encourages you to handle the null case (can't just dereference)
  • Handling the null case is cleaner (via match)
  • It allows the non-nullable value optimisation on raw pointers
  • It only occurs in cases where clarity is more important than conciceness
  • In many of these cases the C bindings will be automatically generated, so it's doesn't matter if it's slightly more verbose
  • Null checks are only needed at the boundary between C and Rust code, rather than in every piece of unsafe code dealing with raw pointers
  • Function pointers (as well as every other pointer type in Rust) are already non-nullable, consistency is important.

RalfJung pushed a commit to RalfJung/rust that referenced this issue Jul 8, 2023
celinval added a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
Fixes were done to address the following upstream changes:

- rust-lang#119606
- rust-lang#119751
- rust-lang#120025
- rust-lang#116520

Resolves rust-lang#2971 

By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 and MIT licenses.
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

4 participants