Array::host, a safe method, can easily cause memory unsafety

[daboross]

Correct me if I'm wrong, but it seems that

arrayfire-rust/src/array.rs

Line 311 in ce74da0

pub fn host<T>(&self, data: &mut [T]) {

checks neither T nor the length of the array to see if they are correct.

In Rust this should either be an unsafe method, or it should have runtime checks on the slice's length and type.

Using host::<String>() for example will give you a bunch of invalid strings - without using unsafe. Using said strings would violate memory safety, and likely cause programs to crash when the strings are deallocated.

I'm really interested in arrayfire in Rust, but it'd be even better if it adhered to Rust library principles. Methods which can violate safety with safe user input should be marked as unsafe to indicate this.

[daboross]

I believe part of this could be solved by requiring T: HasAfEnum on the type, and then making HasAfEnum an unsafe trait.

unsafe traits must be explicitly implemented using unsafe in user code, so the user knows they are doing something unsupported when implementing it.

At least with that, this would no longer be a safety violation (where any T even Box or String can be passed in).

[9prady9]

@daboross Sure, that is a bug - the generic's trait bound is missing for Array::host method.

I believe adding the HasAfEnum trait bound and a check for slice's length against the output of Array::elements() should take care of the memory safety concerns you have expressed. After these changes, do you still think HasAfEnum should be marked unsafe ?

[daboross]

@9prady9 that would be great! I don't think it would need unsafe if it requires HasAfEnum, as it could not cause data unsafety. The length checking would also be good, but I guess it wouldn't be completely necessary if HasAfEnum was required - so that only plain data types could be in the array anyways.