On 10/1/19 5:36 PM, David Laight wrote: >> From: Dan Carpenter >> Sent: 01 October 2019 14:57 >> Subject: Re: [PATCH] staging: rtl8723bs: hal: Fix memcpy calls > ... >> That's true for glibc memcpy() but not for the kernel memcpy(). In the >> kernel there are lots of places which do a zero size memcpy(). > > And probably from NULL (or even garbage) pointers. > > After all a pointer to the end of an array (a + ARRAY_SIZE(a)) is valid > but must not be dereferenced - so memcpy() can't dereference it's > source address when the length is zero. > >> The glibc attitude is "the standard allows us to put knives here" so >> let's put knives everywhere in the path. And the GCC attitude is let's >> silently remove NULL checks instead of just printing a warning that the >> NULL check isn't required... It could really make someone despondent. > > gcc is the one that add knives... > Just found an official documentation to this issue: https://gcc.gnu.org/gcc-4.9/porting_to.html "Null pointer checks may be optimized away more aggressively ... The pointers passed to memmove (and similar functions in <string.h>) must be non-null even when nbytes==0, so GCC can use that information to remove the check after the memmove call. Calling copy(p, NULL, 0) can therefore deference a null pointer and crash." But again, I would say that the bug in this code is because the if condition was copy-pasted and it should be inverted. Thanks, Denis
