PyRawObject API unsafe

[programmerjake]

PyRawObject doesn't track initialization:

#[pyclass]
struct MyType {
    value: String,
}

#[pymethods]
impl MyType {
    #[new]
    fn new(obj: &PyRawObject) -> PyResult<()> {
        obj.init(get_my_type_or_fail()?); // can fail to initialize, dropping uninitialized String
        obj.init(MyType { value: "abc".into() }); // can initialize twice, leaking memory
        Ok(())
    }
}
fn get_my_type_or_fail() -> PyResult<MyType> {
    unimplemented!()
}

PyRawObject doesn't check types:

#[pyclass]
struct MyType {
    value: String,
}
#[pyclass]
struct OtherType {
    value: f32,
}

#[pymethods]
impl MyType {
    #[new]
    fn new(obj: &PyRawObject) {
        obj.init(OtherType {value:1.0}); // initialize with incorrect type
        let value: &OtherType = obj.as_ref(); // get reference with incorrect type
        println!("{}", value.value); // access using incorrect type
    }
}

[programmerjake]

I think it would be pretty common to forget to call init when handling errors, such as by using the ? operator. The rest of these problems are mostly theoretical.

[kngwyu]

Thank you for reporting.
But since I'm planning a huge API modification in this area, I don't want to fix this immediately.

[programmerjake]

Thank you for reporting.
But since I'm planning a huge API modification in this area, I don't want to fix this immediately.

Would you be open to a pull request that just fixes initialization tracking so it panics, doesn't drop uninitialized memory, and/or doesn't double-initialize memory?

That should be pretty easy to do without a user-facing API change, would catch the most common mistake (forgetting to initialize), and can be replaced with your rewritten code when you're ready.

[kngwyu]

OK.
I’ll add simple assertions for that.

[Alexander-N]

Fixed by #683