2006/11/2, Brooks Davis <[EMAIL PROTECTED]>:
On Thu, Nov 02, 2006 at 08:26:27AM +0000, . wrote: > Hi, > > I am confused by the use of inet_ntoa function in the kernel. > > The function inet_ntoa in the /sys/libkern/inet_ntoa.c uses a static array > static char buf[4 * sizeof "123"]; > to store the result. And it returns the address of the array to the caller. > > I think this inet_ntoa is not reentrant, though there are several functions > calling it. If two functions call it simultaneously, the result will be > corrupted. Though I haven't really encountered this situation, it may occur > someday, especially when using multi-processors. > > There is another reentrant version of inet_ntoa called inet_ntoa_r in the > same file. It has been there for several years, but just used by ipfw2 for > about four times in 7-CURRENT. In my patch, I replaced all the calls to > inet_ntoa with calls to inet_ntoa_r. > > By the way, some of the original calls is written in this style: > strcpy(buf, inet_ntoa(ip)) > The modified code is written in this style > inet_ntoa_r(ip, buf) > This change avoids a call to strcpy, and can save a little time. > > Here is the patch. > http://people.freebsd.org/~delphij/misc/patch-itoa-by-nodummy-at-yeah-net > > I've already sent to PR(kern/104738), but got no reply, maybe it should be > discussed here first? I've got to agree with other posters that the stack variable allocations are ugly. What about extending log and printf to understand ip4v addresses? That's 90% of the uses and the others appears to have buffers already. -- Brooks Ugly? Why? Don't you use local variables in your sources?
By the way, implementing a printf/log which understands ipv4 address is tedious, perhaps. _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
