Skip to content

"unsafe" on methods doesn't work #3080

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
bblum opened this issue Aug 1, 2012 · 10 comments
Closed

"unsafe" on methods doesn't work #3080

bblum opened this issue Aug 1, 2012 · 10 comments
Labels
A-type-system Area: Type system E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@bblum
Copy link
Contributor

bblum commented Aug 1, 2012

This compiles, and shouldn't:

enum x = ();
impl x {
    unsafe fn with() { }
}

fn main() {
    x(()).with();
}
@eholk
Copy link
Contributor

eholk commented Aug 1, 2012

This might be related to #2587.

@vertexclique
Copy link
Member

Latest head solved this with throwing error case

@eholk
Copy link
Contributor

eholk commented Nov 26, 2012

I just tried compiling this program with the latest incoming, and it still compiled successfully. @vertexclique, did you say you got an error with this test program?

@catamorphism
Copy link
Contributor

Still wrong as of b60a0be (no error message)

@kud1ing
Copy link

kud1ing commented Feb 6, 2013

Can this be closed? I have a working example of unsafe fn foo() methods.

@pnkfelix
Copy link
Member

Indeed, I am wondering the same thing as kud1ing.

I quickly hacked up an example program that uses unsafe features, and it seems to compile and run properly. (I've included the example at the end of this comment.)

I do not know enough about how traits and methods are implemented, especially in the case of dynamic dispatch in object types, to say that we currently support unsafe methods; all I can see is that we do not obviously fail to support them. :) So I won't close this ticket immediately, but I'd like someone else on the team to consider doing so (or provide me with a pointer to something saying why we do not and/or can not support unsafe methods).


unsafe fn f(x:*int) -> int {
    let p = x as int;
    let q = p + 8; // danger: assumes sizeof(int*) in a vec is 8 !
    let y = q as *int;
    *y
}

trait x { unsafe fn uwith(&self, x:*int) -> int; }
impl x for () {
    unsafe fn uwith(&self, x:*int) -> int {  3+f(x) }
}

impl x for @() {
    unsafe fn uwith(&self, x:*int) -> int { 13+f(x) }
}

impl x for @int {
    unsafe fn uwith(&self, x:*int) -> int { 23+f(x) }
}

fn main() {
    let obju = ();
    let objo = @();
    let obji = @3;
    let vec = [0,7,1000];
    io::print(fmt!("%?\n", obju.uwith(&vec[0])));
    io::print(fmt!("%?\n", objo.uwith(&vec[0])));
    io::print(fmt!("%?\n", obji.uwith(&vec[0])));
}

@pnkfelix
Copy link
Member

(either way, this is not a 0.6 milestone issue.)

@pnkfelix
Copy link
Member

In case it is not clear: I was able to compile and run the code from the comment above. I had meant for this to demonstrate that unsafe methods might be implemented and might work; Niko separately pointed out that the code in the comment also demonstrates that there is a bug, since the calls to the unsafe uwith method should have been required to be enclosed in an unsafe block within their invocations inside main.

@nikomatsakis
Copy link
Contributor

More examples in #6331

@brson
Copy link
Contributor

brson commented Jul 19, 2013

This is fixed.

@brson brson closed this as completed Jul 19, 2013
bors pushed a commit to rust-lang-ci/rust that referenced this issue May 15, 2021
Format macro calls with item-like arguments
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
This is a follow-up to rust-lang#3063 that turns off that MIR pass while
compiling `std` as well to ensure any bugs of the same nature in `std`
are captured by Kani.

Resolves rust-lang#3079
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-type-system Area: Type system E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

No branches or pull requests

8 participants