-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Remove all usages of std.mem.copy
and remove std.mem.set
#18143
Conversation
cc @Vexu for aro |
Just FYI, the typical procedure is to alias things with a |
For the CI failures, should I just change them all to |
The slices need to be the same length to use |
ah i see, they were just done using |
i know what to fix, i just wanna test a couple things tomorrow 😄 i wish there was a way for me to cancel ci actions, because i feel bad about wasting resources 😭 |
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.
Please submit a patch upstream as well!
std.mem.copy
std.mem.copy
and remove std.mem.set
My reasoning for making this PR is 2 reasons.
This should have been simply removed/
@compileError
the first time, and now there is just no point in keeping it around.In my opinion this creates a bad practice function alias. By aliasing
copyForward
, we are creating possible bugs that are not caught and corrupt data due to overlap. The pointer overlap detection of@memcpy
is more important than I believe given credit to. So it leads to the thought that all uses ofstd.mem.copy
(after it was aliased/depricated), were made out of ignorance of the dangerous it could pose to the codebase. If the writer wanted to ensure overlap, they would have / should usecopyForward
, and if they did not want overlap, they need to use@memcpy
.