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? 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...
Rich
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
