Re: [PATCH 5/5] struct sockaddr_storage->ss_family is not portable

["Gary V. Vaughan" <git@mlists.thewrittenword.com>]

Hi Martin,

On Fri, Mar 12, 2010 at 09:24:01AM +0200, Martin Storsj? wrote:
> On Fri, 12 Mar 2010, Gary V. Vaughan wrote:
> > On Thu, Mar 11, 2010 at 06:40:37PM +0200, Martin Storsj? wrote:
> > > On Thu, 11 Mar 2010, Gary V. Vaughan wrote:
> > > 
> > > > Many of our supported platforms do not have this declaration, for
> > > > example solaris2.6 thru 2.7.  Lack of ss_family implies no IPV6
> > > > support, so we can wrap all the ss_family references in an ifndef
> > > > NO_IPV6, and assume sockaddr_in otherwise.
> > > 
> > > While this probably is ok as such, you can actually do the same without 
> > > accessing the sockaddr_storage->ss_family; just cast it to (const struct 
> > > sockaddr*) and use ->sa_family instead, that should work just as well, as 
> > > far as I know.
> > 
> > At least on aix-5.2 it won't be reliable unless you juggle compiler
> > switches just right [...]
> 
> Yes, but if the sockaddr struct can be arranged in different ways, the 
> other ones (sockaddr_in, sockaddr_storage, sockaddr_in6) must also be 
> defined coherently - you're always supposed to be able to cast an 
> sockaddr_in (or any other of them) to a sockaddr and read the sa_family 
> field. As far as I know, at least.

Ah, good point.  And now, having tested that on all our machines it
works perfectly, and is much more elegant!

I'll resubmit presently.

Cheers,
-- 
Gary V. Vaughan (gary@thewrittenword.com)