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]