Array lifetime and type

[bluss]

This is some drive by code review as requested 😄

Issue 1) It looks like the code is not correctly connecting the lifetime of the borrow of the slice with the lifetime that belongs to the reference that comes from the transmute. Here's a testcase that shows an aliasing violation.. we can mutate the data while we have a reference to it!

By the way, for pointers, prefer just using casts instead of transmuting. The same caveat with lifetimes still applies though.

The best way to make sure the lifetimes match up is using a function. For example like copy_lifetime, a function you can copy.

Issue 2) Unrestricted transmute. The user's type parameter is trusted, and the user can get bogus results by giving the wrong type.

[bluss]

If you don't mind, I think I would write it like this. I like the idea behind this code, bounds check and then cast when it's ok. See also this Q & A on SO.

[droundy]

Thanks so much! I had worried about aliasing, but wasn't clear as to how to do this right. I've made those changes, and in addition have made the as_array function generic, which seems to allow type inference to decide the type of the array for us. :)

If you'd care to go for another round of review, I'd be extremely grateful!

[bluss]

Looks good to me. I lifted out $offset, $len outside the unsafe block, but I forgot $arr. I guess just having let slice = &$arr[$offset .. $offset + $len] outside the unsafe block is the best. That way the user can't slip in unsafe code in the $arr expression by mistake.

[droundy]

Thanks for the further suggestion, @bluss ! I hadn't understood why you'd defined a and l before, but now it makes sense. Even though rust macros are hygienic, that doesn't prevent expressions from containing unsafe code, and putting the "let slice =" outside the unsafe block protects from that.