-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Comments
Note that you could still of course write ptr::null in unsafe code by reinterpret_casting between numbers and pointers. |
When would you want to do that instead of writing |
No reason, I'm just noting we can't prevent folks from creating null
|
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. |
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:
|
Automatic sync from rustc
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.
"I am managing the lifetime of this pointer myself" and "I might have null instead of a pointer" should be orthogonal concepts.
I suggest:
*T
is always non-null*T
maps to Rustoption<*T>
in bindings (depends on Tags should be represented using null ptrs where possible #1271)ptr::null
,ptr::is_null
, andptr::is_not_null
go awayThis would help clarify code that uses unsafe pointers.
The text was updated successfully, but these errors were encountered: