Re: squid-3.HEAD IPAddress leak

On Sat, 2008-02-09 at 01:53 +1300, Amos Jeffries wrote:
> Amos Jeffries wrote:
> > Alex Rousskov wrote:
> >> On Fri, 2008-02-08 at 15:52 +1300, Amos Jeffries wrote:
> >>
> >>> The second;
> >>> sockaddr_storage (as Husni uses, and Adrian mentioned) was created to
> >>> provide a better way of using sockaddr* so the sockaddr_in and
> >>> sockaddr_in6 bits could be read-written easily. But the big/litte endian
> >>> problems between OS screwed up the sockaddr_in* sa_family field
> >>> locations
> >>> inside it so developers still can't portably use it for the v6/v6 flag
> >>> they wanted.
> >>
> >> Do you have a reference for that? I do not want to bug you with more
> >> questions but I am surprised to learn that some kind of a
> >> sockaddr_storage wrapper cannot work well for Squid... We may have to
> >> fix Polygraph that is using that approach, IIRC.
> >
> > I don't have any online references. Everything I have found online
> > indicated that the _storage should be padded properly.
> > But, I found in my hex-level debugging of the IPv6 code in squid that
> > some things consistently went badly because the cast sa_family field was
> > something much higher than any IANA protocol family. Its too long ago
> > now to recall exact test cases. May have been a system-specific given
> > this connect() bug.
>
> Correction: I did have online source that were somewhat confusing but
> explained the behaviour a little. This seems to be saying what I
> remember, http://www.kame.net/newsletter/19980604/

Whew! The above link seems to confirm that we should be using
sockaddr_storage as the base for IPAddress wrapper.

Is it possible that you interpreted "use getaddrinfo() and getnameinfo()
everywhere" section _title_ too literally? :-) The actual text of that
section suggests where to use getaddrinfo. I think we are using it for a
lot more than that, right?

Alex.
Received on Fri Feb 08 2008 - 08:19:34 MST