On Thu, 2008-05-22 at 06:34 +0100, 夏Timothy wrote: > And then, I dig into the telnetd.c for both busybox 1.7.2 and 1.10.2, > hoping to find out why busybox 1.7.2 > could not work with arm uClibc toolchain. The followings are my > findings. > > when busybox telnetd receives character from socketd, it would send > the character to pty. Before sending the > character, here are some statements in telnetd.c: > char *ptr; > /* Write to pty from buffer 1. */ > ptr = remove_iacs(ts, &num_totty); > w = safe_write(ts->ptyfd, ptr, num_totty); > > Here is the statement used to return from remove_iacs in busybox 1.72. > return memmove(ptr - num_totty, ptr0, num_totty); > While the code used to return from remove_iacs in busybox 1.10.2 turns > out to be: > if ((ptr - totty) == 0) /* 99.999% of cases */ > return ptr0; > return memmove(ptr - num_totty, ptr0, num_totty); > > It seems memmove returns value 0 so that when the following code > attempts to access *0, error occurs. Thus, it > could explain why busybox 1.7.2 fails but busybox 1.10.2 works since > it returns ptr0 which is safe. > > However, according to GNU Libc definition, the prototype of memmove > is: > void * memmove (void *to, const void *from, size_t size) > And the value returned by memmove should be the value of to. > > Hence, I dig into the code of uClibc that implements memmove. And I > found that for the code of uClibc i386, memmove > does return the value of to. But for uClibc arm, memmove just simply > jumps to a function _memcpy which is implemented > by a bunch of assembly code. I suspected that uClibc arm code does not > implement memmove according to the GNU libc > definition and memmove does not return a value of to, instead, it > returns 0 directly. > > If so, busybox 1.10.2 might also be not totally safe. There still > exists possibility that remove_iacs uses memmove to > return. > > Could anybody help me to provide me with some comments on my > suspicion? Thanks a lot. > > With Regards, > Timothy > >
In general many uclibc functions differ from glibc equivalents in behaviour so do not use the glibc behavior as reference instead look up SUSV3 for reference. However I see that when destination == source than _memcpy returns 0 ISO for memmove and memcpy says that functions should return src always So it seems a bug in arm uclibc to me. Thanks -Khem
signature.asc
Description: This is a digitally signed message part
_______________________________________________ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
