vec::raw::memcpy/memmove do not do bounds checks

[brson]

These functions do memcopies between slices but they do not check that the memory they are reading and writing actually falls inside the vector bounds. They probably should.

[x--]

Pull request: #4378

[cpeterso]

@brson I started to add additional ptr::memcpy() check to assert that its dst and src arguments do not overlap, but then I realized that the assertion would be more overhead than simply calling libc's safer memmove() instead of memcpy().

Would you accept a patch to redirect ptr::memcpy() to libc's memmove() and possibly remove ptr::memmove()? Even renowned micro-optimizer Linus Torvalds [1] and Brian Kernighan and Rob Pike [2] agree that memcpy() should just alias to memmove(). <:)

[1] https://bugzilla.redhat.com/show_bug.cgi?id=638477#c101
[2] https://bugzilla.redhat.com/show_bug.cgi?id=638477#c245

[brson]

@cpeterso These functions in core::ptr are now called copy_memory and copy_overlapping_memory. Now that their name doesn't bear any resemblance to the C functions I would be ok with removing copy_memory and renaming copy_overlapping_memory to copy_memory.

I believe that the vec::raw memory functions now are inconsistently named, since they haven't been updated to follow this new naming convention.

[brson]

@cpeterso you might be interested in #4413 as well

[brson]

Ah, I was wrong. The vec::raw functions did have their names updated.

[pnkfelix]

Not critical for 0.6; de-milestoning

[emberian]

This is fixed in incoming, I believe.