Simon Josefsson <si...@josefsson.org> writes: > I recall looking into this some time ago. I found that some of the uses > of this function are for IPv4-only code paths. And then I found it hard > to argue for change. > > Is there anything other wrong with inet_ntoa? If there is no other > fundamental problem, I think we can keep using it even if POSIX removes > it. It is a well known interface, and seems appropriate to use in a > IPv4-only code path. > > What is not appropriate are IPv4-only code paths to begin with. But > fixing that is a much larger change... and some stuff in InetUtils is > IPv4-only by nature. > > But +1 to do this, but please consider this aspect and stat with the > places which are IPv4+IPv6 code paths.
Thanks for the additional information. Gnulib doesn't provide inet_ntoa because of the IPv6 issue. But also, in my opinion, it is a poorly designed function beyond that. It writes to a static buffer so it cannot be used in multi-threaded applications (Glibc makes the buffer thread-local, but that is not required by the standard). Since Inetutils programs are single-threaded though there is no harm in using inet_ntoa for IPv4-only paths. > I think 'pkg_add help2man' works on OpenBSD. Yep, you are right. I was mistaken when I said OpenBSD didn't have a help2man port [1]. Must have been looking in the wrong place, oops. Collin [1] https://github.com/openbsd/ports/tree/master/devel/help2man
