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

From: Gary V. Vaughan <git@mlists.thewrittenword.com>
Date: Apr 26, 2010, 16:55 UTC
Message-ID: <20100426165522.GC28004@thor.il.thewrittenword.com>
In-Reply-To: <alpine.DEB.2.00.1004252204020.24585@cone.home.martin.st>

On Sun, Apr 25, 2010 at 10:05:16PM +0300, Martin Storsj? wrote:

> Hi Gary,

Hi Martin,

There's unfortunately a 1 month time slip between my having written the messages and having figured out why they were being rejected (actually 3 things that needed fixing before resends started arriving, which is why it took so long)...

Show 17 quoted lines

> On Sun, 25 Apr 2010, Gary V. Vaughan wrote:
> 
> > On Fri, Mar 12, 2010 at 09:24:01AM +0200, Martin Storsj? wrote:
> > > 
> > > 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.
> 
> Actually, Brandon Casey already submitted a patch doing this, which is 
> available in master by now, so this issue is all taken care of. :-)

...and I didn't notice that until I started rebasing the changesets against a newer release.

Excellent that one issue is now resolved though, I'll repost my outstanding patches presently.

Cheers,

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