Hi, On Sat, Jul 28, 2012 at 7:46 PM, Arnaud Lacombe <lacombar_at_gmail.com> wrote: > Hi, > > On Sat, Jul 28, 2012 at 6:44 PM, Bjoern A. Zeeb > <bzeeb-lists_at_lists.zabbadoz.net> wrote: >> Which again leaves me with the question - why does libc have it? >> > as for the semantic, theoretical, "why", I would refer you to the > POSIX's comity, as inet_ntop() is part of it. > actually, it is slightly more complicated than that. POSIX has inet_ntoa(), inet_ntop() and no inet_ntoa_r(). libc's inet_ntoa{,_r}() are implemented on top inet_ntop(), which *does* fail if the provided buffer is not large enough, and set errno to ENOSPC. However, inet_ntoa{,_r}() do not propagate inet_ntop() failure. As for the userland version of inet_ntoa{,_r}(), I would change it to at least stop ignoring inet_ntop() return value, add an assertion on its success, drop this awful `strcpy(ret, "[inet_ntoa error]");' and use the proper size in inet_ntoa() definition. As for the kernel version... it is a lost cause to argue one way or another... - ArnaudReceived on Sat Jul 28 2012 - 23:39:07 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:29 UTC