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.
