Section on uninitialized memory

[Manishearth]

No description provided.

[Manishearth]

Ready for review!

[djkoloski]

Isn't the issue here that ptr is dangling after x is moved, not that the value at ptr is necessarily uninitialized?

[Manishearth]

I feel like it's both, right? It can be analyzed through the framework of dangling pointers or through the framework of uninit.

[Darksonn]

I think it is misleading to talk about deallocated and uninitialized memory in the same way. Reads from deallocated memory are insta-UB, whereas reads from uninitialized memory might not be UB if you're reading it as a type such as MaybeUninit<u8>.

[Manishearth]

Yeah I'm going to rewrite this section. I'll keep it in since it's similar to uninitialized memory, so worth thinking about, but not the same.

[Manishearth]

I've reworked this a bit, thoughts?

[Darksonn]

I would reword this to start by talking about freed allocations. Then end the section by saying that moving out of a local variable is like deallocating the memory because the compiler might reuse that location on the stack for another local.

[Manishearth]

I'm hesitant to do too much here because I suspect that coverage may live better in a separate chapter. I mentioned freed memory a bit, though.

[Manishearth]

not super happy with the flow of the chapter here, I think it's important to talk about this but I'm not sure where it should go. We have spent a lot of time talking about where uninitialized values come from, but not talking about what actually is safe vs unsafe about it.

[Manishearth]

I'm happier with it now but I think "Safely working with uninit" is now not the right name for the section

[Darksonn]

I haven't yet looked at anything below ## When you might end up making an uninitialized value

[Darksonn]

I would reword this to start by talking about freed allocations. Then end the section by saying that moving out of a local variable is like deallocating the memory because the compiler might reuse that location on the stack for another local.

[Darksonn]

Here is some guidance on specific situations that involve uninit memory:

1. When using Vec::set_len to add elements to a vector, you are supposed to initialize the memory before you call set_len.
2. Given an &mut [MaybeUninit<u8>] where some of the bytes are already initialized, its possible to deinitialize them. This means that passing the &mut [MaybeUninit<u8>] to unknown user code and expecting those bytes to still be initialized is not sound. This is the origin of things like UninitSlice.
3. If you use MaybeUninit on a field and then later do let var = var.assume_init(); when you've initialized it can sometimes optimize poorly. In these cases, you can create a &mut T that points into the MaybeUninit and just use the reference directly. However, this requires extra care if T has a destructor.
4. When mixing MaybeUninit with UnsafeCell, you should do UnsafeCell<MaybeUninit<T>> rather than MaybeUninit<UnsafeCell<T>>.
5. When going from *mut Struct to *mut Field, it's best practice to use addr_of! or addr_of_mut! for the conversion if the struct is uninitialized.

[Manishearth]

Probably can incorporate some of @Darksonn's feedback in a separate PR