Re: Incomplete getaddrinfo module

[Simon Josefsson]

Yoann Vandoorselaere <address@hidden> writes:

> On Thu, 2005-09-15 at 17:36 +0200, Simon Josefsson wrote:
>> Yoann Vandoorselaere <address@hidden> writes:
>> 
>> > If  the  AI_ADDRCONFIG flag is specified, IPv4 addresses shall be
>> > returned only if an IPv4 address is configured on the local system, and
>> > IPv6 addresses shall be returned only if an IPv6 address is configured
>> > on the local system.
>> 
>> This looks tricky to implement.  Looking at libc code, it uses
>> getifaddrs, which appear tricky to implement portably.  But we could
>> support multiple implementations of getifaddrs, one for each system
>> where we know how to implement it.  I don't see how we could hope to
>> do better.
>
> In the meantime, a good workaround would be to remove the definition for
> AI_ADDRCONFIG from GnuLib provided getaddrinfo.h. This way, application
> can test for the flag and avoid to use it if it is not present.

Yes, this may work.

> Libprelude for example won't use AI_ADDRCONFIG in case the header does
> not export it because this is known to not be portable. However, since
> GnuLib export the flags, it get used, and getaddrinfo() will fails due
> to the usage of unsupported flags.

On the other hand, if the AI_ADDRCONFIG flag is POSIX, applications
really should not have to test for it.  The gnulib approach is that
applications assume POSIX, and is written for that.  Maybe it is
better to use a runtime test, i.e.:

rc = getaddrinfo (...AI_ADDRCONFIG...)
if (rc == EAI_BADFLAGS) {
   /* Try it without AI_ADDRCONFIG, we may have the incomplete gnulib
      getaddrinfo implementation, or the system implementation may not
      support AI_ADDRCONFIG. */
   rc = getaddrinfo(......)
}
...normal error checking...

What do people think?

I do not know of any other getaddrinfo implementations that lack
support of AI_ADDRCONFIG, though.

Btw, perhaps it is possible to implement something clever to portably
figure out whether IPv4 or IPv6 is configured on the local machine.
How about trying to send a packet to the 127.0.0.1 or ::1/128?  That
should work if IPv4/IPv6 is properly configured, right?  And sending
shouldn't be that difficult.  Maybe it is even sufficient to try to
bind a server socket for IPv4 or IPv6.  Or something.

Thanks,
Simon