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

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

Closed
jdm opened this Issue Jan 29, 2013 · 6 comments

Comments

Projects
None yet
5 participants
@jdm
Contributor

jdm commented Jan 29, 2013

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

This comment has been minimized.

Show comment
Hide comment
@jdm

jdm Jan 29, 2013

Contributor

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

Contributor

jdm commented Jan 29, 2013

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

@ghost ghost assigned jdm Feb 20, 2013

@pnkfelix

This comment has been minimized.

Show comment
Hide comment
@pnkfelix

pnkfelix Apr 29, 2013

Member

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:

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.

Member

pnkfelix commented Apr 29, 2013

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:

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

This comment has been minimized.

Show comment
Hide comment
@jdm

jdm Apr 29, 2013

Contributor

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.

Contributor

jdm commented Apr 29, 2013

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

This comment has been minimized.

Show comment
Hide comment
@graydon

graydon May 2, 2013

Contributor

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

Contributor

graydon commented May 2, 2013

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

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis May 2, 2013

Contributor

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?

Contributor

nikomatsakis commented May 2, 2013

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

This comment has been minimized.

Show comment
Hide comment
@thestinger

thestinger Jun 3, 2013

Contributor

@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.

Contributor

thestinger commented Jun 3, 2013

@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.

@thestinger thestinger closed this Jun 3, 2013

@jdm jdm removed their assignment Jun 16, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment