Skip to content

move_val_init causes wierd breakage #3917

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

Closed
brson opened this issue Nov 4, 2012 · 5 comments
Closed

move_val_init causes wierd breakage #3917

brson opened this issue Nov 4, 2012 · 5 comments
Labels
A-codegen Area: Code generation
Milestone

Comments

@brson
Copy link
Contributor

brson commented Nov 4, 2012

From Blub:

fn main() {
    // this line causes the madness
    let mut _done: ~[bool] = vec::from_fn(4, |_x| { false });

    let input = io::stdin();
    let line = read_line(input);

    io::println(fmt!("got %?", line));
}

fn read_line(input: @io::Reader) -> ~str {
    let mut bytes = ~[];
    loop {
        let ch = input.read_byte();
        if ch == -1 || ch == 10 { break; }
        bytes.push(ch as u8);
    }
    str::from_bytes(bytes)
}
This is obviously wrong:

wry:tmp/ $ rustc order.rs && echo aaa | ./order
got ~"\x01\x01\x01"

It gets fixed when I move the read_line() function *above* main.
(same thing happens with input.read_line() from io::ReaderUtil btw)

removing the vec::from_fn() line fixes it too...

Also, changing the type of vec _done from ~[bool] to ~[anything else] makes it go away.

@Blub
Copy link

Blub commented Nov 5, 2012

I replaced vec::from_fn with a my_from_fn which instead of rusti::move_val_init simply uses a = move b and this also seems to fix it. Maybe move_val_init doesn't honor the type-sizes correctly and writes out of bounds somewhere? (Without that change the copied function causes the same problem)

The function is a copy&paste from libcore/vec.rs with only the marked line exchanged

pub pure fn my_from_fn<T>(n_elts: uint, op: iter::InitOp<T>) -> ~[T] {
    unsafe {
        let mut v = vec::with_capacity(n_elts);
        do vec::as_mut_buf(v) |p, _len| {
            let mut i: uint = 0u;
            while i < n_elts {
                //vec::rusti::move_val_init(&mut(*ptr::mut_offset(p, i)), op(i)); <-- change here
                *ptr::mut_offset(p, i) = move op(i); // new code
                i += 1u;
            }
        }
        vec::raw::set_len(&mut v, n_elts);
        return move v;
    }
}

I don't know exactly rusti::move_val_init does, so, hope this information helps somehow.

@Blub
Copy link

Blub commented Nov 5, 2012

Ah, in fact, the whole testcase can be reduced: Drop the _done and vector creation completely, here's the new minimal testcase:

use io::ReaderUtil;
fn main() {
    let mut x: bool = false;
    // this line breaks it
    vec::rusti::move_val_init(&mut x, false);

    let input = io::stdin();
    let line = input.read_line(); // use core's io again

    io::println(fmt!("got %?", line));
}
wry:tmp/ $ rustc order.rs && echo aaa | ./order
got ~"\x01\x01\x01"

@brson
Copy link
Contributor Author

brson commented Nov 5, 2012

Updated title to reflect problem

@nikomatsakis
Copy link
Contributor

though I don't see why it would cause this problem, this use of move_val_init is invalid. The init is supposed to mean that this intrinsic is used to initialize the memory being moved into. That is, it expects the memory to be uninitialized and hence does not drop the previous value (which is garbage). Here of course the memory is initialized, but then... this is a boolean value, so it shouldn't matter.

@pcwalton
Copy link
Contributor

pcwalton commented Dec 6, 2012

This is a problem with type_use.

RalfJung pushed a commit to RalfJung/rust that referenced this issue Sep 29, 2024
bump rustc-build-sysroot version

This removes an implicit `--cap-lints` in the sysroot build. Let's see if that causes any trouble for the targets we test.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-codegen Area: Code generation
Projects
None yet
Development

No branches or pull requests

4 participants