do we need inet_ntop check?

Andrew Dunstan <andrew@dunslane.net> writes:

Currently the IPv6 check in configure.in says this:

HAVE_IPV6=no
AC_CHECK_TYPE([struct sockaddr_in6],
[AC_CHECK_FUNC(inet_ntop,
[AC_DEFINE(HAVE_IPV6, 1, [Define to 1 if
you have support for IPv6.])
HAVE_IPV6=yes])],
[],
[$ac_includes_default
#include <netinet/in.h>])
AC_SUBST(HAVE_IPV6)

However, we don't use inet_ntop anywhere in our code that I can see,
either in the HEAD or REL8_0_STABLE branch. So why do we need that extra
check (which fails on Windows)?

I can't see any reason for it either. AFAICT, all we actually depend
on to compile the #ifdef HAVE_IPV6 code is (a) struct sockaddr_in6 and
(b) the macro AF_INET6. Arguably we should have an explicit test for
the latter, but unless someone exhibits a header file that has the
struct but not the macro, the struct test seems sufficient.

I'll remove the configure test. I assume you want it gone from the 8.0
branch too...

regards, tom lane

Tom Lane wrote:

AFAICT, all we actually depend
on to compile the #ifdef HAVE_IPV6 code is (a) struct sockaddr_in6 and
(b) the macro AF_INET6. Arguably we should have an explicit test for
the latter, but unless someone exhibits a header file that has the
struct but not the macro, the struct test seems sufficient.

I'll remove the configure test. I assume you want it gone from the 8.0
branch too...

Yes please.

Unfortunately, this doesn't get us over the IPv6 hump on Windows, not
even if we include ws2tcpip.h.

It appears that we need either to pull in getaddrinfo from ws2_32.dll
(which Windows platforms have this? It should be available for them all,
according to MSDN). or make out own routines decipher ipv6 addresses.
So far today I haven't had any luck with the former.

cheers

andrew