[PATCH 4/5] include: Add wmemmove to wchar.h

Chris Robinson chris.kcat at gmail.com
Sun May 27 23:37:45 CDT 2018


On 05/27/2018 09:17 PM, Alex Henrie wrote:
> On Sun, May 27, 2018 at 9:20 PM Dmitry Timoshkov <dmitry at baikal.ru> wrote:
> 
>> Alex Henrie <alexhenrie24 at gmail.com> wrote:
> 
>>> +static inline wchar_t* __cdecl wmemmove(wchar_t *dst, const wchar_t
> *src, size_t n)
>>> +{
>>> +    size_t i;
>>> +    if (dst <= src) return wmemcpy(dst, src, n);
>>> +    for (i = 1; i <= n; i++)
>>> +        dst[n - i] = src[n - i];
>>> +    return dst;
>>> +}
> 
>> The optimization with wmemcpy() looks arbitrary and not safe.
> 
> It looks perfectly safe to me. Can you give an example of valid inputs that
> would cause memory corruption?

Is there any guarantee about how pointers relate to each other? Is it 
related to the pointer's bit pattern interpreted as some integer type, 
or as if the pointers were casted/converted to some integer type? And is 
it a signed or unsigned comparison?

Also, checking dst <= src, even with the expected results, doesn't 
guarantee the two memory ranges don't overlap. Aside from when dst==src, 
if dst = src - i and n > i, the tail of dst would overlap the head of src.



More information about the wine-devel mailing list