On Tue, Aug 9, 2011 at 10:41 PM, Rich Felker <[email protected]> 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 > [email protected] > http://lists.busybox.net/mailman/listinfo/uclibc > _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
