-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Avoid calling memcpy with NULL pointers #305
Conversation
I think adding a branch in |
Are you concerned about the performance? I have not seen any difference caused by this change. |
If the objective is to prevent calling if (count) {
data_.a.elements = (GenericValue*)allocator.Malloc(count * sizeof(GenericValue));
std::memcpy(data_.a.elements, values, count * sizeof(GenericValue));
}
else
data_.a.elements = 0;
data_.a.size = data_.a.capacity = count;
|
Oh, you're right. |
PR updated, see 0c5c153. |
According to the C/C++ standards, calling `memcpy(NULL, NULL, 0)` is undefined behaviour. Recent GCC versions may rely on this by optimizing NULL pointer checks more aggressively, see [1]. This patch tries to avoid calling std::memcpy with zero elements. As a side effect, explicitly return NULL when requesting an empty block from MemoryPoolAllocator::Malloc. This may be related to Tencent#301. [1] https://gcc.gnu.org/gcc-4.9/porting_to.html
1 similar comment
Avoid calling memcpy with NULL pointers
I added a test case and also standardize CrtAllocator::Malloc() in 0e8bbe5. |
Thanks! 👍 |
According to the C/C++ standards, calling
memcpy(NULL, NULL, 0)
is undefined behaviour. Recent GCC versions may rely on this by optimizing NULL pointer checks more aggressively, see [1].This patch tries to avoid calling std::memcpy with zero elements. As a side effect, explicitly return NULL when requesting an empty block from MemoryPoolAllocator::Malloc.
This may be related to #301. Opening the pull-request as requested by @miloyip.
[1] https://gcc.gnu.org/gcc-4.9/porting_to.html