RFC: Add std::mem::zero

[nvzqz]

Rendered

This is a functionality that's already possible in stable Rust, but I think it's well worth adding to libcore and transitively to libstd.

I would also like to be the one to implement this feature.

[SimonSapin]

Note that intrinsics::write_bytes is available on stable Rust at ptr::write_bytes, so this three-line function can be defined outside of the standard library.

[nvzqz]

This is added functionality that I think complements mem::zeroed nicely. I'm aware this is available in stable Rust. There are plenty of small functions in the standard library, though. I wrote this to gauge community opinion on whether this seems like a useful addition (to me it is).

[iitalics]

Seems an opportunity for lots of UB

[eddyb]

@nvzqz It'd be nice to at least change this to ptr::write_bytes.

[mgattozzi]

@iitalics in the cases of mem::zeroed and mem::unitialized UB is quite possible thus the functions are marked as unsafe and the documentation with them describes how to use it without causing UB. Adding another function like this really isn't a problem in that sense as long as it is marked as unsafe and it is documented on how to use it safely. These functions have a place when doing things with FFI or other low level operations. This is just an extension of that.

[mark-i-m]

will work with both slices and trait objects

Is this intended as a good thing? I might be wrong, but it seems like zeroing a trait object is always undefined behavior, right? Why would you want to zero a vtable?

[eddyb]

Why would you want to zero a vtable?

The vtable pointer isn't in the trait object data though, it's in the fat pointer, next to the data pointer.

[mark-i-m]

So zeroing a trait object does not mean this?

let x: &mut Any;
unsafe { mem::zero(x) };

[eddyb]

@mark-i-m that's distinct from mem::zero(&mut x) (which would null the data and vtable pointers).

[notriddle]

Can a post-monomorphization lint check if mem::zero is being run on a &mut N where N: NonZero<T> (including, but not limited to, zeroing out a reference)?

Being able to do that seems like a good reason to include in in the standard library. Because that seems super easy to get wrong.

[bstrie]

Even if this can be expressed outside of the stdlib, one of the primary features of the stdlib is to give some assurance that unsafe functions have been considered and vetted. When it comes to unsafe utility functions I am very much in favor of stdlib maximalism--as long as someone finds it useful, that is.

That said, this function as proposed doesn't actually guarantee that the data is zeroed, correct? If not, then cryptography implementations will find this function lacking. Is that worth supporting?

[eddyb]

We could have a volatile_zero function for the crypto usecase.

[scottmcm]

one of the primary features of the stdlib is to give some assurance that unsafe functions have been considered and vetted

I'm not convinced by that for unsafe functions. I find the checking of the safe APIs that use unsafe internally incredibly valuable (like Ralf's work on Mutex), but the value seems much lower for an unsafe function that fairly-simply wraps another unsafe function.

[nvzqz]

If the function is already unsafe, does it make sense to require a mutable reference instead of a raw pointer? And if using a raw pointer makes more sense, should this (or these) function(s) be in std::ptr instead?

[kennytm]

The &mut &mut T problem can be delegated to clippy: if we write let x = zeroed() or zero(&mut x) where x has a non-zeroable type (&T, &mut T, Box<T>), issue a warning. I don't think this needs to be in rustc.

Or you could create an auto trait...

auto trait MaybeZeroSafe {}
impl<T: Zeroable> !MaybeZeroSafe for NonZero<T> {}
impl<T: ?Sized> !MaybeZeroSafe for &T {}
impl<T: ?Sized> !MaybeZeroSafe for &mut T {}
impl !MaybeZeroSafe for /*** all kinds of function pointers ***/ {}

unsafe fn zero<T: ?Sized + MaybeZeroSafe>(x: &mut T) {}

... this feels extremely heavy-handed though.

[bstrie]

one of the primary features of the stdlib is to give some assurance that unsafe functions have been considered and vetted

I'm not convinced by that for unsafe functions. I find the checking of the safe APIs that use unsafe internally incredibly valuable

@scottmcm I consider these the same concern though: unsafe code is unsafe code. The difference is just that a safe API has zero invariants that callers must uphold, and an unsafe API has one or more invariants that callers must uphold; if the unsafe code inside an unsafe function is incorrectly implemented, there may secretly exist undocumented invariants that can result in surprising cases of memory unsafety. Just because a function is marked as unsafe, it doesn't mean that it can't still be inherently safer than other functions marked unsafe. :)

[Restioson]

unsafe API has one or more invariants that callers must uphold

While this is true, unsafe code should still try to be as safe as possible. In this case, making it take *mut T stops it from violating the guarantee that &mut T must point to valid data for a type.

[SimonSapin]

The libs team discussed this today and we felt that this is too niche to be part of the standard library:

@rfcbot fcp close

Especially given that:

• This is literally a three-line function that can be defined outside of the standard library (std::ptr::write_bytes is stable, and now also as a <*mut T>::write_bytes method)
• That function is still an unsafe fn, so it doesn’t remove much safety hazard from callers

With manual inlining, the example in the RFC simplifies to one line:

fn clear_bytes(slice: &mut [u8]) {
    unsafe { slice.as_mut_ptr().write_bytes(0, slice.len()) }
}

[rfcbot]

Team member @SimonSapin has proposed to close this. The next step is review by the rest of the tagged teams:

• @Kimundi
• @SimonSapin
• @alexcrichton
• @dtolnay
• @sfackler
• @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[Restioson]

Personally, I want this. I found myself causing a stack overflow with

*ptr = mem::zeroed::<VeryLargeT>();

Naturally, I next looked for mem::zero(ptr); and found it not to exist. I think that it does complement mem::zeroed, although it is quite niche. In the case that it is not included in core, where should it go?

[dtolnay]

@Restioson with write_bytes I would write this as:

ptr.write_bytes(0u8, 1);

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[Restioson]

@dtolnay I did settle for that in the end, but it feels like something that "you shouldn't have to define yourself" although you can.

[rfcbot]

The final comment period, with a disposition to close, as per the review above, is now complete.

By the power vested in me by Rust, I hereby close this RFC.