apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm MacCarthaigh <c...@stdlib.net>
Subject Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Date Thu, 07 Jun 2007 00:49:06 GMT
On Thu, Jun 07, 2007 at 03:38:39AM +0300, Lucian Adrian Grijincu wrote:
> a) either have different behaviour on different platforms (Ubuntu 7.4
> (and everything based on it)  vs. the rest).

AI_ADDRCONFIG behaviour is not supported on plenty of platforms yet,
yes, but it's backwards compatible, it's a safe default too, I
don't see how the difference in behaviour affects users of the API.
As long as you do:

	linked-list-result = apr_sockaddr_info_get ("opaque-string") 

	foreach node in linked-list-result do:
		listen() or connect() 

there is no problem. The problem *only* arises if you use
apr_sockaddr_info_get("::1") and some kind of niaive "do I have working
IPv6" test. But it's a resolver, nothing else, that usage falls outside
of common or reasonable behaviour IMO. 

On platforms that support the AI_ADDRCONFIG behaviour our users get to
avoid an unneccessary listen() or connect() call (and corresponding
delay and timeout). This is a big win!
> b) or document that this function must not be used with strings
> representing link-local IPv6 IPs or hostnames to link-local IPv6 IPs.

link-local addresses are something else again, but you can getaddrinfo()
a link-local address just fine, if you really want to.  Don't expect it
to be very useful in a L3 application though!

> Did I understand right?

No :-)

> >> What good would APR_NUMERIC_ADDRESS do in this case?
> >
> >Like I said, that is not the use-case.
> I first understood that you were referring to the use-case of
> "hostnames to IPv6 link-local IPs" in relation to
> apr_sockaddr_info_get, not APR_NUMERIC_ADDRESS. Sorry it's kindof
> early in the morning on my side of the planet and I'm subject to
> self-imposed sleep-deprivation.

I've never mentioned link-local IPs! The use-case I was responding about
is the one in the test, namely wanting "::1" to always resolve, no
matter what. That's a very special case (for which apr_inet_pton or an
entirely different approach are better suited). 

Colm MacCárthaigh                        Public Key: colm+pgp@stdlib.net

View raw message