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: [EMAIL PROTECTED]
