> #include<stdio.h>
> #include<string.h>
>
> int main()
> {
> char *str1[10] = {src};
> char *str2[10] = {dest};
> memcpy(str1, str2, -1);
>
> return 1;
> }
Depending on your gcc version and the compilation options you're using,
this program's behaviour might have nothing to do with the libc, because
memcpy() is magically recognized by gcc, which inlines optimized code
for your architecture.
If you made sure the libc's memcpy() was called, then yes, you exhibited
a behaviour difference between glibc and uClibc... and nobody should care
because said behaviour is undefined so anything is fair game.
I would guess that the glibc goes out of its way to check that the
memcpy() arguments are valid and makes a point to crash when they are
not, with is a safe behaviour but requires extra code, whereas the
uClibc does not perform such checks, and may crash or may happily
copy 4 GB of memory all over the place, or fly demons through your nose.
--
Laurent
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
