Re: do we need inet_ntop check?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: do we need inet_ntop check?
Date: 2005-08-17 19:54:07
Message-ID: 6469.1124308447@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2005-08-17 20:14:01 Re: pl/Ruby, deprecating plPython and Core
Previous Message Tom Lane 2005-08-17 19:40:53 Re: PATCH to allow concurrent VACUUMs to not lock each