-
Notifications
You must be signed in to change notification settings - Fork 721
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
refactor: make memmove vs memcpy behavior clearer #4447
Conversation
558e904
to
6fb4e46
Compare
@@ -15,7 +15,7 @@ | |||
|
|||
#include "utils/s2n_safety.h" | |||
|
|||
void *s2n_ensure_memcpy_trace(void *restrict to, const void *restrict from, size_t size) | |||
void *s2n_ensure_memmove_trace(void *to, const void *from, size_t size) |
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.
Is there a reason why this function is called _trace?
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.
History: https://github.com/aws/s2n-tls/blame/9014236e7ba83869251298341264ccf1a37cd9f6/utils/s2n_ensure.c#L18-L24 Looks like it used to manually set the debug string.
But now the only work it really does is to check the result of memmove. The higher level macros could probably just do that themselves.
I opened an issue to remove it: #4457 I'd still like to merge this, as it's a step in the right direction.
Description of changes:
6648c66 switched us from using memcpy to memmove, but didn't remove the "restrict" keywords on the arguments. This can cause analysis tools like asan and valgrind to flag arguments with overlapping memory.
This PR removes the keywords, and also switches the definition of the safety macros to specify "memmove" instead of "memcpy" to reduce confusion.
However, I do NOT change the actual names of the safety macros, so most of our code will still use RESULT_CHECKED_MEMCPY or POSIX_CHECKED_MEMCPY. But now the fact that those macros use memmove instead is clear from their definitions, rather than requiring digging through several more layers. We can always change the safety macro names in a later PR, but I'm not sure it's necessary.
Testing:
There should be no behavior change, and existing tests pass.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.