negative memcpy

Denys Vlasenko vda.linux at googlemail.com
Thu Aug 11 12:32:04 UTC 2011


On Thu, Aug 11, 2011 at 6:53 AM, manish kumar <deliver2manish at gmail.com> wrote:
> On Thu, Aug 11, 2011 at 9:53 AM, Denys Vlasenko
> <vda.linux at googlemail.com> wrote:
>> ...but the below doesn't look like memcpy from uclibc:
>> in iclibc tree, uClibc/libc/string/mips/memcpy.S is hardly
>> 5 screenfuls of code including comments,
>> and it, for example, doesn't use "pref" instruction
>> (and never did according to git log).
>>
>> Whereas code below is HUGEST: nearly FORTY screenfuls,
>> and it uses "pref" insn.
>>
>> Google code search failed to find the source
>> (I looked for "memcpy detect_done").
>>
>> Is this a modified uclibc, with someone's
>> "more optimized" memcpy?
>
> My  uClibc/libc/string/mips/memcpy.S is different from the uClibc
> tree. I guess it is optimized one for the target. Anyway, how can it
> copy such a huge data?

I suspect it doesnt copy anything at all, because
memcpy exit condition is likely "cnt <= 0".
(I don't know MIPS assembly enough to check it).
In "sanely" sized memcpy's, cnt, when interpreted as signed int32,
is > 0, but in your case it is < 0 already.

> Or is it not copying anything when ssize_t = -1?

I think yes.

IOW: I think the "optimized" memcpy code in your
uclibc tree is buggy.

-- 
vda


More information about the uClibc mailing list