-
Notifications
You must be signed in to change notification settings - Fork 13k
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
ptr::copy_nonoverlapping
is not memcpy
#113347
The head ref may contain hidden characters: "memcpy-\u3058\u3083\u306A\u3044"
Conversation
A C implementation may treat memcpy calls Rust expects `ptr::copy_nonoverlapping` to handle correctly as UB. Stop confusing the matter.
Similar comments appear in rust/library/core/src/ptr/mut_ptr.rs Line 1452 in beb0e73
|
Oh, lovely. |
Co-authored-by: Ralf Jung <post@ralfj.de>
These intrinsics have a divergent meaning from C's own, so stop trying to tell people that they are the same.
Most docs are not actually referring to the symbol memcpy, so do not refer to that symbol.
Note that I am leaving the aliases in place quite on-purpose: if someone is determined to search for that name, finding these functions and reading them is fine by me. |
/// `copy` is semantically equivalent to C's [`memmove`], but with the argument | ||
/// order swapped. Copying takes place as if the bytes were copied from `src` | ||
/// to a temporary array and then copied from the array to `dst`. | ||
/// `copy` may temporarily use additional space to copy bytes from `src` into an array, before |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't it just copy forwards/backwards depending on which region is "lower"? I don't think you ever need a temporary array?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
arguably a register is in fact a "temporary array", but you're right, I think.
This reference to memset seems to still be around? rust/library/core/src/ptr/mut_ptr.rs Line 1452 in beb0e73
|
!@#$%^&* |
Co-authored-by: Ralf Jung <post@ralfj.de>
LGTM apart from that last open thread, feel free to resolve either way. But let's also get more eyes on this since we are removing the documentation's references to the C function equivalents entirely: |
Note that I am happy to readd documentation like what I removed if insisted-upon, but instead explaining more clearly that it is a false friend. The element vs. byte confusion, in particular, is something I will be landing a fix for today in another Rust-based software repo. It is really bad out there! |
The comment is there to some extent to tell people that if they're coming from C-land and would normally use memcpy/memmove/memset then these are the rusty replacements. |
(Based on some discussion I had off-thread with @workingjubilee) The thing is, there are many languages people come from, not just C. So should a comparison with C really be but front and center, before even our own list of safety requirements? |
We do give C a bit of a special treatment here and there, since it's mentioned in the |
Alright, I think that's reasonable. |
r? libs |
@workingjubilee any updates on this? thanks |
Somewhat hilariously, this PR has become much more incorrect, as it is almost exactly memcpy now that WG14 has declared an intent to validate |
Thanks :D. Closing this pr then :) |
A C implementation may treat memcpy calls Rust expects
ptr::copy_nonoverlapping
to handle correctly as UB. Stop confusing the matter.r? @RalfJung