Make unsafe pointers always non-null

[jruderman]

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

I suggest:

• Rust *T is always non-null
• C++ *T maps to Rust option<*T> in bindings (depends on Tags should be represented using null ptrs where possible #1271)
• ptr::null, ptr::is_null, and ptr::is_not_null go away

This would help clarify code that uses unsafe pointers.

[pcwalton]

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

[jruderman]

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

[pcwalton]

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]

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]

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.