Skip to content
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

Closed

Conversation

workingjubilee
Copy link
Member

A C implementation may treat memcpy calls Rust expects ptr::copy_nonoverlapping to handle correctly as UB. Stop confusing the matter.

r? @RalfJung

A C implementation may treat memcpy calls Rust expects
`ptr::copy_nonoverlapping` to handle correctly as UB.
Stop confusing the matter.
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jul 5, 2023
library/core/src/intrinsics.rs Outdated Show resolved Hide resolved
library/core/src/intrinsics.rs Outdated Show resolved Hide resolved
@workingjubilee workingjubilee added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools and removed T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jul 5, 2023
@RalfJung
Copy link
Member

RalfJung commented Jul 5, 2023

Similar comments appear in copy and write_bytes (saying they are like memmove and memset), so those should also be updated. It's not just the intrinsics, we also have this here:

/// Invokes memset on the specified pointer, setting `count * size_of::<T>()`

@workingjubilee
Copy link
Member Author

Oh, lovely.

workingjubilee and others added 3 commits July 5, 2023 09:00
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.
@workingjubilee
Copy link
Member Author

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
Copy link
Member

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?

Copy link
Member Author

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.

@RalfJung
Copy link
Member

RalfJung commented Jul 5, 2023

This reference to memset seems to still be around?

/// Invokes memset on the specified pointer, setting `count * size_of::<T>()`

@workingjubilee
Copy link
Member Author

!@#$%^&*

workingjubilee and others added 2 commits July 5, 2023 10:01
@RalfJung
Copy link
Member

RalfJung commented Jul 5, 2023

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:
r? libs-api

@rustbot rustbot assigned joshtriplett and unassigned RalfJung Jul 5, 2023
@workingjubilee
Copy link
Member Author

workingjubilee commented Jul 5, 2023

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!

@the8472
Copy link
Member

the8472 commented Jul 5, 2023

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.
If the comment has to say "like memcpy, but different", that's fine.

@RalfJung
Copy link
Member

RalfJung commented Jul 5, 2023

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

@the8472
Copy link
Member

the8472 commented Jul 5, 2023

We do give C a bit of a special treatment here and there, since it's mentioned in the #[doc(alias=...)] attribute which directs people to the function if they're searching for that. It could probably be buried further down. After they have been directed there it would be good to to explicitly explain how it differs from memcpy.

@workingjubilee
Copy link
Member Author

Alright, I think that's reasonable.
@rustbot author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 8, 2023
@joshtriplett
Copy link
Member

r? libs

@rustbot rustbot added the T-libs Relevant to the library team, which will review and decide on the PR/issue. label Feb 11, 2024
@rustbot rustbot assigned cuviper and unassigned joshtriplett Feb 11, 2024
@Dylan-DPC
Copy link
Member

@workingjubilee any updates on this? thanks

@workingjubilee
Copy link
Member Author

Somewhat hilariously, this PR has become much more incorrect, as it is almost exactly memcpy now that WG14 has declared an intent to validate memcpy(NULL, NULL, 0) in C2y.

@Dylan-DPC
Copy link
Member

Thanks :D. Closing this pr then :)

@Dylan-DPC Dylan-DPC closed this Oct 12, 2024
@Dylan-DPC Dylan-DPC removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Oct 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools T-libs Relevant to the library team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants