Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3F4A370F.6010807@attglobal.net>
Date: Mon, 25 Aug 2003 12:19:27 -0400
From: Jeff Trawick <trawick@attglobal.net>
Reply-To: trawick@attglobal.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: dev@apr.apache.org
Subject: Re: [Patch] IPv6 on Tru64 broken
References: <20030825155238.GA1579@castlerea.stdlib.net.>
In-Reply-To: <20030825155238.GA1579@castlerea.stdlib.net.>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Colm MacCarthaigh wrote:

> IPv6 with Apache on tru64 has been broken for a while now, and I finally 
> got round to figuring out what it was. It appears that Tru64's
> getaddrinfo returns ai_addrlen of 32 for AF_INET6 address, but that
> sizeof(struct sockaddr_in6) is 28.
> 
> This meant that apr_sockaddr_vars_set() was blindly setting salen
> to 28, and then later when Apache called bind( , , 28) Tru64 bombed
> out in unpleasant error land. Patch attached. 

I'm not sure I would use the word "blindly", as we're using 
sizeof(sockaddr_in6).  If getaddrinfo() returns IPv6 addresses larger 
than that, we're hosed at that point and shouldn't be copying into the 
apr_sockaddr_info_t anyway.

Isn't the first step to see why getaddrinfo() is returning IPv6 
addresses larger than sizeof(sockaddr_in6) and take it from there? 
(Alternatively, why am I confused?)