Re: [PATCH 5/5] struct sockaddr_storage->ss_family is not portable
- From
Martin Storsjö <martin@martin.st>
- Date
- Mar 12, 2010, 07:24 UTC
- Message-ID
- <alpine.DEB.2.00.1003120922040.29993@cone.home.martin.st>
- In-Reply-To
- <20100312045654.GH7877@thor.il.thewrittenword.com>
On Fri, 12 Mar 2010, Gary V. Vaughan wrote:
Show 33 quoted lines
> 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 (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 */
> };
> #endifYes, 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.
// Martin