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

From: Gary V. Vaughan <git@mlists.thewrittenword.com>
Date: Mar 12, 2010, 04:56 UTC
Message-ID: <20100312045654.GH7877@thor.il.thewrittenword.com>
In-Reply-To: <alpine.DEB.2.00.1003111838260.29993@cone.home.martin.st>

On Thu, Mar 11, 2010 at 06:40:37PM +0200, Martin Storsj? wrote:

Show 11 quoted lines

> 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 (I didn't check anywhere else, but the precedent for the bit ordering of the struct members being different is already set):

#if defined(COMPAT_43) && !defined(_KERNEL)
struct sockaddr {
        ushort_t        sa_family;      /* address family */
        char            sa_data[14];    /* up to 14 bytes of direct
address */
};

#else
struct sockaddr {
        uchar_t         sa_len;         /* total length */
        sa_family_t     sa_family;      /* address family */
        char            sa_data[14];    /* actually longer; address value */
};
#endif

Cheers,
   Gary

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