Stream: t-compiler/const-eval

Topic: mem::forget lack of guarantees


pnkfelix (Jul 08 2019 at 10:39, on Zulip):

Someone pointed out to me on my recent blog post that mem::forget explicitly does not guarantee that pointers to the forgotten memory remain valid

pnkfelix (Jul 08 2019 at 10:44, on Zulip):

Could miri check this? (AFACIT it currently does not; see lines 15-17 of linked playpen.) And if it could, should it?

oli (Jul 09 2019 at 15:03, on Zulip):

https://github.com/rust-lang/miri/issues/753

oli (Jul 09 2019 at 15:04, on Zulip):

I think it should be enough to make moves invalidate (set to undef) the bytes that are moved out of

oli (Jul 09 2019 at 15:04, on Zulip):

But that may end up becoming rather slow (especially since that's what's happening in many cases already via StorageDead)

oli (Jul 09 2019 at 15:05, on Zulip):

For moves via ptr::read this may not be an option, not sure.

RalfJ (Jul 11 2019 at 15:40, on Zulip):

I think the game is still open whether mem::forget kills pointers

RalfJ (Jul 11 2019 at 15:40, on Zulip):

seems strange to me honestly, it does explicilty not deallocate

RalfJ (Jul 11 2019 at 15:41, on Zulip):

I think it should be enough to make moves invalidate (set to undef) the bytes that are moved out of

that's not enough, then you can still write to that memory

RalfJ (Jul 11 2019 at 15:41, on Zulip):

I have not seen an operational model that lets us actually formalize this. and I dont believe in axiomatic semantics. ;)

oli (Jul 12 2019 at 12:12, on Zulip):

oh

oli (Jul 12 2019 at 12:13, on Zulip):

my mental model of moves is just undefing the memory that you move out of

RalfJ (Jul 13 2019 at 07:45, on Zulip):

yes we have talked about that before. I just am still waiting to see a case where that actually enables any optimization.^^

RalfJ (Jul 13 2019 at 07:45, on Zulip):

I thought it was useful. But I am not so sure any more.

Last update: Nov 15 2019 at 21:20UTC