Repository navigation
Array lifetime and type聽#1
Description
Activity
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.
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!
Looks good to me. I lifted out
$offset,$lenoutside the unsafe block, but I forgot$arr. I guess just havinglet 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.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.
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.