New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
brson opened this Issue Dec 14, 2012 · 7 comments

Comments

Projects
None yet
6 participants
@brson
Contributor

brson commented Dec 14, 2012

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--

This comment has been minimized.

Show comment
Hide comment
@x--

x-- Jan 8, 2013

Pull request: #4378

x-- commented Jan 8, 2013

Pull request: #4378

@cpeterso

This comment has been minimized.

Show comment
Hide comment
@cpeterso

cpeterso Jan 13, 2013

Contributor

@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

Contributor

cpeterso commented Jan 13, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jan 14, 2013

Contributor

@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.

Contributor

brson commented Jan 14, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jan 14, 2013

Contributor

@cpeterso you might be interested in #4413 as well

Contributor

brson commented Jan 14, 2013

@cpeterso you might be interested in #4413 as well

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jan 14, 2013

Contributor

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

Contributor

brson commented Jan 14, 2013

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

@pnkfelix

This comment has been minimized.

Show comment
Hide comment
@pnkfelix

pnkfelix Mar 25, 2013

Member

Not critical for 0.6; de-milestoning

Member

pnkfelix commented Mar 25, 2013

Not critical for 0.6; de-milestoning

@cmr

This comment has been minimized.

Show comment
Hide comment
@cmr

cmr Jun 8, 2013

Member

This is fixed in incoming, I believe.

Member

cmr commented Jun 8, 2013

This is fixed in incoming, I believe.

@thestinger thestinger closed this Jun 12, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment