Unfortunately I think the only reason that fixed your segfault is because you're now leaking that memory indefinitely. If we ignore the "T must have the same size and alignment" line, your issue is that your third arg should be 560/80 not 560. It's in elem count not bytes
-
-
-
Replying to @b0rk
The memory allocated by your vector is never freed. `slice` doesn't own its memory, and thus doesn't free it.
2 replies 0 retweets 0 likes -
Replying to @sgrif
i don't mem::forget the vector so i think rust will free it?
1 reply 0 retweets 0 likes -
Replying to @b0rk
Oh I must have misread your post, I thought you said you were mem::forgetting it -- My mistake!
1 reply 0 retweets 0 likes -
Replying to @sgrif
oh yea i switched from mem::forgetting to not mem::forgetting. i will clarify that's confusing!!
1 reply 0 retweets 0 likes -
Replying to @b0rk
You mentioned "I think this might actually still violate some memory safety guarantees" -- I don't think so, as long as `rb_control_frame_struct` is `#[repr(C)]`
1 reply 0 retweets 1 like -
Replying to @sgrif
i was worried that maybe my vec won't actually be backed by contiguous memory under the hood for some reason?
1 reply 0 retweets 0 likes -
Replying to @b0rk
`Vec` is always backed by contiguous memory. It's just an array with a capacity to store how many more elements you can put in it before reallocating. It's implemented more or less identically to Ruby's Array if that helps at all
1 reply 0 retweets 0 likes -
No problem. (Sorry for "well actuall"-ing your mentions :\)
-
-
Replying to @sgrif
honestly i'm trying to understand this stuff out so I appreciated being corrected when I'm wrong! =)
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.