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

Topic: Writing into uninit structs


Elichai Turkel (Jan 15 2020 at 13:00, on Zulip):

Hi, this look like it should be UB but Miri doesn't complain and it seems like Rc is doing similar stuff: https://play.rust-lang.org/?gist=51690e4dd9d723e5b64b6a37280aa5ae
thoughts? (if this isn't the place for questions like that please tell me :) )

Elichai Turkel (Jan 15 2020 at 13:11, on Zulip):

Ha! found it! https://github.com/rust-lang/unsafe-code-guidelines/issues/77 I remember these things were talked about in the group.
most of the talk seem to be on uninhabitable types though

RalfJ (Jan 15 2020 at 16:25, on Zulip):

yeah Miri doesnt currently check that references point to something valid

Elichai Turkel (Jan 16 2020 at 13:34, on Zulip):

@RalfJ Is that valid though? Because my example is a simple variation of what happens when You call Rc::new_uninit()

RalfJ (Jan 16 2020 at 17:45, on Zulip):

Well, you've found https://github.com/rust-lang/unsafe-code-guidelines/issues/77

RalfJ (Jan 16 2020 at 17:45, on Zulip):

so, as you can see -- the discussion is still open

RalfJ (Jan 16 2020 at 17:46, on Zulip):

for now we should assume it to be not allowed, but also gather good use-cases for allowing references that are aligned and dereferencable but point to invalid data

Elichai Turkel (Jan 17 2020 at 13:44, on Zulip):

@RalfJ well in the Rc case we could just replace with alloc_zeroed, right? that way the usize's aren't invalid anymore because 0 is a valid usize and then you the reference points to a zeroed struct full of zero allowed primitives except the last one T which is inside a MaybeUninit so that's fine.

RalfJ (Jan 17 2020 at 18:47, on Zulip):

well sure, but should it really be necessary to zero-init things?

RalfJ (Jan 17 2020 at 18:48, on Zulip):

sorry I also lost context here, not sure what the question/goal is^^

Elichai Turkel (Jan 18 2020 at 11:16, on Zulip):

Sorry. I'll try to be focused and concise.
A. Seems like there's no agreement if that's allowed but it might not be.
B. If it might not be allowed why Rc doesn't just zeroize the memory so it would be valid (or maybe they see no reason to do that until there's a decision on validity?)

comex (Jan 19 2020 at 10:08, on Zulip):

Zero-init is undesirable because it has performance cost. If it is decided that whatever Rc is doing is illegal (I haven’t looked), it should be fixed, but in a way that’s zero-overhead, using MaybeUninit or something. That said, since Rc is in the standard library which is versioned along with the compiler, it’s not super urgent to fix theoretical UB if it’s known that the current compiler doesn’t exploit it. Which is not to say it’s not important, if only because people will reference the standard library when making their own types.

Elichai Turkel (Jan 19 2020 at 11:04, on Zulip):

Zero-init is undesirable because it has performance cost. If it is decided that whatever Rc is doing is illegal (I haven’t looked), it should be fixed, but in a way that’s zero-overhead, using MaybeUninit or something. That said, since Rc is in the standard library which is versioned along with the compiler, it’s not super urgent to fix theoretical UB if it’s known that the current compiler doesn’t exploit it. Which is not to say it’s not important, if only because people will reference the standard library when making their own types.

Well right now rust doesn't let you calculate fields offsets in a "safe" way

centril (Jan 19 2020 at 18:24, on Zulip):

if only because people will reference the standard library when making their own types.

I feel we need to raise more awareness that this is a bad idea and double down more on documenting the specialness of assumptions that the standard library makes in // SAFETY comments

Last update: Feb 25 2020 at 03:50UTC