negative memcpy

[manish kumar]

On Tue, Aug 9, 2011 at 10:41 PM, Rich Felker <dalias at aerifal.cx> wrote:
> On Tue, Aug 09, 2011 at 10:22:25PM +0900, manish kumar wrote:
>> #include<stdio.h>
>> #include<string.h>
>>
>> int main()
>> {
>>    char *str1[10] = {src};
>>    char *str2[10] = {dest};
>>    memcpy(str1, str2, -1);
>>
>>   return 1;
>> }
>>
>> This simple test case of negative memcpy() fails on PC with glibc, but
>> executes well on uClibc on MIPS target. -1 should translate to a large
>> positive number and while doing memcpy(), program should access
>> illegal memory and should get segmentation fault. This happens on PC
>> with glibc environment.
>>
>> Why this program runs on uClibc?
>
> You mean it fails to crash?

Yes, it fails to crash. The program exits normally.

>Technically you've invoked undefined
> behavior by passing a length greater than the destination (and source)
> buffer size to memcpy, so "anything" could happen, but I suspect there
> may be a bug. Of course, unless it's possible to make allocations
> larger than SIZE_MAX/2, what memcpy does with "negative" size
> arguments is irrelevant since they're always invalid. It seems the
> standards don't outright forbid allocations this large, but if you
> make them, performing pointer arithmetic within the allocated block
> can overflow and invoke dangerous undefined behavior, so malloc should
> probably be denying such allocations anyway...
>
This test case crashes in my PC with glibc and also with some memory
debuggers like DUMA.So I was expecting similar behavior with uClibc
also. I checked the memcpy() code of uClibc, but there is nothing much
there.

> Rich
> _______________________________________________
> uClibc mailing list
> uClibc at uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc
>