Safe memset for slices

[sethjackson]

RFC 1419 implemented safe memcpy but not memset.
It would be awesome if we could fill slices with data in a safe manner that would lower into memset.

Currently if I want to fill a slice with memset semantics I have to do this:

unsafe {
    ptr::write_bytes(self.slice.as_mut_ptr(), 0, self.slice.len() - 1);
}

I would like to be able to do something like this:

self.slice.fill(0);

[SimonSapin]

Would this only exist for [u8]? Or be unsafe? Writing arbitrary bytes to arbitrary types is not valid in the general case. For examples the items of [&T] are not allowed to be null.

[burdges]

Would adding a method to Default make sense?

[mark-i-m]

I think a slightly more general impl would be a blanket impl like

impl<T: Copy> [T] {
    pub fn fill(val: T) {
        for i in self.iter_mut() {
            *i = val;
        }
    }
}

[sethjackson]

@SimonSapin I would like fill (or whatever the chosen method name would be) to lower into memset (ptr::write_bytes) for at least all primitives and be safe. Like copy_from_slice does for memcpy.

Basically I would like a safe memset for slices like there exists a safe memcpy.

[SimonSapin]

@sethjackson Right, I understand the goal, it’s just more tricky to get there than with copy_from_slice.

First, would the argument to [T]::fill be u8 or T? If the former, how do you make it safe for arbitrary Ts? If the latter, for size_of::<T>() > 1, do you check that each byte of the value is identical to call write_bytes, and have a fallback code path if they’re not? Or have a default impl like @mark-i-m wrote, and use specialization for primitive integer types? What about other types like [char] or [*const T] or [Option<&T>] or [(u16, u16)]? memset to zero would be safe for those, but other values not necessarily.

[sethjackson]

Ah I see.

I was thinking the argument would be T. Like C++'s std::array::fill. I think in that case a default impl could be provided and then specialize the primitive impls like you mentioned.

[mark-i-m]

@sethjackson Right, that's what I was going for too.

[abonander]

The implementation doesn't have to lower to memset, it could hit a vectorized write loop instead. It could have a check for if the bytes of the value are all the same (ignoring padding) and lower to memset then.

[mark-i-m]

Hmm... I guess I was imagining that it would be something the compiler optimizes away, rather than explicitly writing code to choose...

…

On Jul 22, 2017 9:58 PM, "Austin Bonander" ***@***.***> wrote: The implementation doesn't have to lower to memset, it could hit a vectorized write loop instead. It could have a check for if the bytes of the value are all the same (ignoring padding) and lower to memset then. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2067 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIazwDyEwLsqP-K1BnDEQwPm-rC4w1lBks5sQqjPgaJpZM4OZIFP> .

[abonander]

LLVM can still optimize it, of course. I'm just thinking about performance improvement for dynamic values.

[joshtriplett]

@sethjackson (and others) For anything other than [u8] and equivalent, do you need full memset, or do you just need zeroing?

[sethjackson]

@joshtriplett not sure I understand. What do you mean by full memset or just zeroing?

For [u8] and equivalent I would like fill(val: T) to memset. For other types where fill can't memset I don't want zeroing I want it to fill the slice with the value specified to fill ( the value passed to fill could be something other than zero).

[bluss]

I would prefer this a generic method using either T: Copy or T: Clone. The details are a matter of implementation quality, but it's not complicated to guarantee that it's like memset when T is a byte.

impl<T> [T] {
    fn fill(&mut self, value: T) where T: Copy { ... }
}

For T: Copy we can even write our own multi-byte splat function with simd down the line, if needed.

(An alternative could potentially be a generalization, that it instead is a method on iterators - implemented for Iterator<Item=&mut T>. With specialization we can still recover memset for &mut [u8].)

[Techcable]

You could have an unsafe trait ArbitraryBytes {} that guarantees a type can be filled with arbitrary bytes and used with fill_bytes.
It could be safely implemented for all the primitive integers, without implementing it for floating point types or references. The fill_bytes method could be safely and directly lowered to a very fastmemset without the cost of a general solution for all Copy types.

In fact, this abstraction is already possible in stable rust. Hopefully, something like this will be added to nightly soon.

[joshtriplett]

@Techcable We could also have a parent trait of that, for types that permit zero-filled memory as a valid representation. Floating-point types can implement that, too, as can Option.