Stream: t-lang/wg-unsafe-code-guidelines

Topic: ref to uninitialized memory


gnzlbg (Dec 10 2018 at 18:11, on Zulip):

@RalfJ miri says that the following is ok: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=e68a01cfb3d769ae90690c60e6511eec

Does that mean that references to uninitialized memory can be ok ?

briansmith (Dec 10 2018 at 18:17, on Zulip):

I'm pretty sure you have to allow that because lots of code already uses it.

briansmith (Dec 10 2018 at 18:17, on Zulip):

Has anybody tried to extend the borrow checker to allow "write-only" borrows?

briansmith (Dec 10 2018 at 18:18, on Zulip):

In fact, there's a lot of existing code that does the same thing, except foo() itself takes a reference and initializes the memory using the reference.

RalfJ (Dec 10 2018 at 21:53, on Zulip):

miri doesn't reject all the things I would like it to reject ;) mostly because we haven't decided about the invariants yet

RalfJ (Dec 10 2018 at 21:54, on Zulip):

there are two things that code does which are worth discussing: it has an uninitialized integer (I think that should be UB), and it has a reference to an uninitialized integer (I think that should be fine)

RalfJ (Dec 10 2018 at 21:55, on Zulip):

but @gnzlbg in general, you shouldnt take "miri accepts it" has "UB-free". there are things that are not implemented, and there are things where the checks are not as aggressive as I could make them because I want to see how the UCG discussions go first.

gnzlbg (Dec 10 2018 at 21:56, on Zulip):

makes sense

gnzlbg (Dec 10 2018 at 21:56, on Zulip):

that example is pretty much an idiom that the rsmpi crate uses ~a million times.

RalfJ (Dec 10 2018 at 21:59, on Zulip):

@gnzlbg well mem::uninitialized is going to get deprecated. how would you have written that with MaybeUninit?

gnzlbg (Dec 10 2018 at 21:59, on Zulip):

the proper way

RalfJ (Dec 10 2018 at 22:00, on Zulip):

@gnzlbg could you write some code? "proper" isn't very explicit ;)

gnzlbg (Dec 10 2018 at 22:00, on Zulip):

MaybeUninit has an as_mut_ptr method that makes it trivial to pass "out" parameters to C

RalfJ (Dec 10 2018 at 22:00, on Zulip):

oh you just need raw ptrs anyway

RalfJ (Dec 10 2018 at 22:00, on Zulip):

yeah then it's probably easy

gnzlbg (Dec 10 2018 at 22:02, on Zulip):

@RalfJ https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=d6962e8e6098a191ef97bcd653630232

RalfJ (Dec 10 2018 at 22:02, on Zulip):

yeah that looks perfect :)

gnzlbg (Dec 11 2018 at 08:13, on Zulip):

@RalfJ so how is my initial example using uninitialized UB in a world with your RFC about &mut T as *mut T ?

gnzlbg (Dec 11 2018 at 08:14, on Zulip):

the user writes &mut T, but that reference is never put into a place, it is never dereferenced, and it is coerced / casted into a raw pointer before the result of the expression it is in is put into a place

RalfJ (Dec 11 2018 at 08:15, on Zulip):

@RalfJ so how is my initial example using uninitialized UB in a world with your RFC about &mut T as *mut T ?

see the int/float point in https://github.com/rust-rfcs/unsafe-code-guidelines/pull/54 ;)

RalfJ (Dec 11 2018 at 08:15, on Zulip):

if I have my way, let x: i32 = mem::uninitialized(); is UB

RalfJ (Dec 11 2018 at 08:16, on Zulip):

because you can only have uninitailized data inside a union

RalfJ (Dec 11 2018 at 08:16, on Zulip):

if, OTOH, uninitialized integers are valid, then of course &i32 is also valid when it points to something uninitialized, even with the strongest possible rules for integers

gnzlbg (Dec 11 2018 at 08:23, on Zulip):

ah ok, because it violates the validity of i32, that makes sense

gnzlbg (Dec 11 2018 at 08:25, on Zulip):

time to have some coffee, i just had a deja-vu

gnzlbg (Dec 11 2018 at 08:56, on Zulip):

@RalfJ is a bit of topic here, but I saw your reply in the RFC for the new mir operator, does that mean that if &t as &T as *const T as &T as *const T creates a raw pointer directly ?

gnzlbg (Dec 11 2018 at 09:01, on Zulip):

I wonder if the UCG would need to mention that in the validity of references somehow

gnzlbg (Dec 11 2018 at 09:02, on Zulip):

or whether that's up to the language to specify that coercion chains that create raw pointers are "atomic"

RalfJ (Dec 11 2018 at 09:11, on Zulip):

does that mean that if &t as &T as *const T as &T as *const T creates a raw pointer directly ?

no

RalfJ (Dec 11 2018 at 09:12, on Zulip):

by saying as &T, you are explicitly requesting a reference, not a raw ptr

RalfJ (Dec 11 2018 at 09:12, on Zulip):

but that expression would trigger the lint

gnzlbg (Dec 11 2018 at 10:07, on Zulip):

@RalfJ so I think it might be worth to consider such an extension

gnzlbg (Dec 11 2018 at 10:07, on Zulip):

there was also the issue of x as _ where _: &T creates a reborrow, even though at the end everything is coerced to a raw pointer

gnzlbg (Dec 11 2018 at 10:10, on Zulip):

While those are all different issues, I'm starting to think that it's problematic for as and coercion chains to actually borrow / create references if they end up in a raw pointer

RalfJ (Dec 11 2018 at 10:12, on Zulip):

I think if you write as &T you asked for a reference pretty clearly, it would be strange not to do that

RalfJ (Dec 11 2018 at 10:12, on Zulip):

but as _ shouldn't infer a reference type unless necessary (that's #56604)

Last update: Nov 19 2019 at 17:35UTC