Do we commit to supporting "0 as T*" to express null const expression?

[jdm]

Original title: "Can't use null unsafe pointers in const expressions"

We can't use ptr::null(), since that requires a function call. There's nothing castable, even with #4531 fixed. Maybe we could allow casting literal zero to unsafe pointer types?

[jdm]

Hmm, according to rusti you can cast integer literals to unsafe pointers without any trouble. Looks like this is a const-specific limitation.

[pnkfelix]

This seems to "work" now:

static w : *int = 0 as *int;
fn main() {
    let wval : int;
    io::println(fmt!("w: %u", w as uint));
    io::println(fmt!("w == null: %b", w == ptr::null()));
    unsafe { wval = *w; }
    io::println(fmt!("*w: %d", wval));
}

which when run does:

% /tmp/bug7
w: 0
w == null: true
Segmentation fault: 11

---

At first I was hesitant to claim that this would mean that the bug is fixed, since historically some machine architectures have not used 0 to represent the null pointer at the machine level:

• http://c-faq.com/null/machexamp.html
• http://stackoverflow.com/questions/2597142/when-was-the-null-macro-not-0
• http://stackoverflow.com/questions/2599207/can-a-conforming-c-implementation-define-null-to-be-something-wacky

but since I guess the as operator is analogous to a C cast and is used here to convert the int to a pointer, I think that provides us the ability to commit to supporting the above pattern.

I'm going to nominate this for the backwards compatibility milestone, since handling of NULL seems like the kind of thing we should solidify at that point.

[jdm]

For my purposes the issue is fixed; one of my series of const-related commits added the ability to cast integer types to pointers. I suspect that filing a new issue that laid out @pnkfelix's remaining concerns and nominating that would be slightly more productive.

[graydon]

Check on what C++ nullptr means / does here. For the time being, "yes".

[nikomatsakis]

From what I can tell, the C++ nullptr_t has more to do with overloading based on arguments---that is, one problem with using 0 as a NULL was that it could be interpreted as either an integer or a pointer. Reinterpret casting nullptr to an integer has the same semantics as reinterpret casting (void*)0, which I guess is...semi-defined?

[thestinger]

@nikomatsakis: Yeah, they added nullptr only because using a zero constant often calls an overload you didn't expect it to without even warning about ambiguity. C++ defines NULL as 0 instead of (void *)0 because the latter would then require casts to the specific pointer type.

Rust now treats casts to and from a raw pointer as a safe operation, so the original bug here is fixed. I'm going to close this and we can open another one if there are any lingering issues.