Hi,
On Sat, Jul 28, 2012 at 7:46 PM, Arnaud Lacombe <lacom...@gmail.com> wrote:
> Hi,
>
> On Sat, Jul 28, 2012 at 6:44 PM, Bjoern A. Zeeb
> <bzeeb-li...@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...
- Arnaud
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
