threads / patch / 22991

patch, 5 partsstruct sockaddr_storage->ss_family is not portable

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

## tl;dr

17 messages between Mar 11, 2010 and Apr 26, 2010. Diffs are folded; open one to read it.

replies: 16people: 5as markdown or json

Gary V. Vaughan· Mar 11, 2010, 16:37 UTC · lore

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.

Actually, the test for setting NO_IPV6 at configure time is still
too optimistic and I have to manually pass '-DNO_IPV6' in CPPFLAGS
at build time on aix-5.2.0.0 and earlier, and irix-6.5 and older
for them to pick up the right branch.
---
 daemon.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

Show changes to daemon.c +7 −1

diff --git a/daemon.c b/daemon.c
index 6bc1c23..c9ea500 100644
--- a/daemon.c
+++ b/daemon.c
@@ -591,17 +591,23 @@ static int execute(struct sockaddr *addr)
 static int addrcmp(const struct sockaddr_storage *s1,
     const struct sockaddr_storage *s2)
 {
+#ifndef NO_IPV6
 	if (s1->ss_family != s2->ss_family)
 		return s1->ss_family - s2->ss_family;
 	if (s1->ss_family == AF_INET)
 		return memcmp(&((struct sockaddr_in *)s1)->sin_addr,
 		    &((struct sockaddr_in *)s2)->sin_addr,
 		    sizeof(struct in_addr));
-#ifndef NO_IPV6
 	if (s1->ss_family == AF_INET6)
 		return memcmp(&((struct sockaddr_in6 *)s1)->sin6_addr,
 		    &((struct sockaddr_in6 *)s2)->sin6_addr,
 		    sizeof(struct in6_addr));
+#else
+	/* Assume AF_INET or equivalent for the likes of Solaris 2.7,
+	   HP/UX 11.00 and others do not implement ss_family */
+	return memcmp(&((struct sockaddr_in *)s1)->sin_addr,
+	    &((struct sockaddr_in *)s2)->sin_addr,
+	    sizeof(struct in_addr));
 #endif
 	return 0;
 }

-- 
1.7.0.2

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

Martin Storsjö· Mar 11, 2010, 16:40 UTC · re: Gary V. Vaughan · lore

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

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.

// Martin

Gary V. Vaughan· Mar 12, 2010, 04:56 UTC · re: Martin Storsjö · lore

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

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)

Martin Storsjö· Mar 12, 2010, 07:24 UTC · re: Gary V. Vaughan · lore

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

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 */
> };
> #endif

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.

// Martin

Brandon Casey· Mar 15, 2010, 21:03 UTC · re: Martin Storsjö · lore

[PATCH] daemon.c: avoid accessing ss_family member of struct sockaddr_storage

From: Brandon Casey <drafnel@gmail.com>

When NO_SOCKADDR_STORAGE is set for a platform, either sockaddr_in or sockaddr_in6 is used intead. Neither of which has an ss_family member. They have an sin_family and sin6_family member respectively. Since the addrcmp() function accesses the ss_family member of a sockaddr_storage struct, compilation fails on platforms which define NO_SOCKADDR_STORGAGE.

Since any sockaddr_* structure can be cast to a struct sockaddr and have its sa_family member read, do so here to workaround this issue.

Thanks to Martin Storsjö for pointing out the fix, and Gary Vaughan for drawing attention to the issue.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
 daemon.c |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

Show changes to daemon.c +5 −3

diff --git a/daemon.c b/daemon.c
index 3769b6f..8a52fdc 100644
--- a/daemon.c
+++ b/daemon.c
@@ -590,9 +590,11 @@ static int execute(struct sockaddr *addr)
 static int addrcmp(const struct sockaddr_storage *s1,
     const struct sockaddr_storage *s2)
 {
-	if (s1->ss_family != s2->ss_family)
-		return s1->ss_family - s2->ss_family;
-	if (s1->ss_family == AF_INET)
+	if (((const struct sockaddr*) s1)->sa_family !=
+	    ((const struct sockaddr*) s2)->sa_family)
+		return ((const struct sockaddr*) s1)->sa_family -
+		       ((const struct sockaddr*) s2)->sa_family;
+	if (((const struct sockaddr*) s1)->sa_family == AF_INET)
 		return memcmp(&((struct sockaddr_in *)s1)->sin_addr,
 		    &((struct sockaddr_in *)s2)->sin_addr,
 		    sizeof(struct in_addr));

-- 
1.6.6.2

Jeff King· Mar 15, 2010, 21:29 UTC · re: Brandon Casey · lore

Re: [PATCH] daemon.c: avoid accessing ss_family member of struct sockaddr_storage

On Mon, Mar 15, 2010 at 04:03:00PM -0500, Brandon Casey wrote:

Show 8 quoted lines

> When NO_SOCKADDR_STORAGE is set for a platform, either sockaddr_in or
> sockaddr_in6 is used intead.  Neither of which has an ss_family member.
> They have an sin_family and sin6_family member respectively.  Since the
> addrcmp() function accesses the ss_family member of a sockaddr_storage
> struct, compilation fails on platforms which define NO_SOCKADDR_STORGAGE.
> 
> Since any sockaddr_* structure can be cast to a struct sockaddr and
> have its sa_family member read, do so here to workaround this issue.

Didn't Gary say that AIX 5.2 sticks sa_len at the front of their sockaddr?

We know that whatever we actually have (an actual sockaddr_storage, or a sockaddr_in, or a sockaddr_in6) will have the family at the front, so can you just cast it to sa_family_t?

Or am I wrong in assuming that, and on AIX sockaddr_in actually has sa_len at the front, so casting to sockaddr does the right thing (and my recommendation above would actually be broken)? The AIX boxen I have access to are all down at the moment.

-Peff

Martin Storsjö· Mar 15, 2010, 21:41 UTC · re: Jeff King · lore

Re: [PATCH] daemon.c: avoid accessing ss_family member of struct sockaddr_storage

On Mon, 15 Mar 2010, Jeff King wrote:

Show 13 quoted lines

> On Mon, Mar 15, 2010 at 04:03:00PM -0500, Brandon Casey wrote:
> 
> > When NO_SOCKADDR_STORAGE is set for a platform, either sockaddr_in or
> > sockaddr_in6 is used intead.  Neither of which has an ss_family member.
> > They have an sin_family and sin6_family member respectively.  Since the
> > addrcmp() function accesses the ss_family member of a sockaddr_storage
> > struct, compilation fails on platforms which define NO_SOCKADDR_STORGAGE.
> > 
> > Since any sockaddr_* structure can be cast to a struct sockaddr and
> > have its sa_family member read, do so here to workaround this issue.
> 
> Didn't Gary say that AIX 5.2 sticks sa_len at the front of their
> sockaddr?

Yes, but if they have it in sockaddr, they have it in sockaddr_in (and should have it in sockaddr_storage, if it defines such fields at all). Those structs should always be defined so that their sa_family/ss_family/sin_family/sin6_family fields match.

Show 8 quoted lines

> We know that whatever we actually have (an actual sockaddr_storage, or a
> sockaddr_in, or a sockaddr_in6) will have the family at the front, so
> can you just cast it to sa_family_t?
> 
> Or am I wrong in assuming that, and on AIX sockaddr_in actually has
> sa_len at the front, so casting to sockaddr does the right thing (and my
> recommendation above would actually be broken)? The AIX boxen I have
> access to are all down at the moment.

Generally, I don't think one can assume much about the layout of these structs, there may be this sa_len field on some implementations.

But you should always be able to cast a sockaddr_in or sockaddr_in6 or sockaddr_storage to a sockaddr, to examine its sa_family field, in order to know what to cast it to.

// Martin

Brandon Casey· Mar 15, 2010, 21:42 UTC · re: Jeff King · lore

Re: [PATCH] daemon.c: avoid accessing ss_family member of struct sockaddr_storage

On 03/15/2010 04:29 PM, Jeff King wrote:

Show 17 quoted lines

> On Mon, Mar 15, 2010 at 04:03:00PM -0500, Brandon Casey wrote:
> 
>> When NO_SOCKADDR_STORAGE is set for a platform, either sockaddr_in or
>> sockaddr_in6 is used intead.  Neither of which has an ss_family member.
>> They have an sin_family and sin6_family member respectively.  Since the
>> addrcmp() function accesses the ss_family member of a sockaddr_storage
>> struct, compilation fails on platforms which define NO_SOCKADDR_STORGAGE.
>>
>> Since any sockaddr_* structure can be cast to a struct sockaddr and
>> have its sa_family member read, do so here to workaround this issue.
> 
> Didn't Gary say that AIX 5.2 sticks sa_len at the front of their
> sockaddr?
> 
> We know that whatever we actually have (an actual sockaddr_storage, or a
> sockaddr_in, or a sockaddr_in6) will have the family at the front, so
> can you just cast it to sa_family_t?

I expect that the layout of the sockaddr_* family of structures will follow the layout of struct sockaddr, otherwise they wouldn't be compatible.

In other words, I think that if struct sockaddr looks like this:

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

then somewhere else, struct sockaddr_in looks like this:

  struct sockaddr_in {
        uchar_t         sin_len;
        sin_family_t    sin_family;
        sin_port;
        sin_addr;
        ...
  };

> Or am I wrong in assuming that, and on AIX sockaddr_in actually has
> sa_len at the front, so casting to sockaddr does the right thing (and my
> recommendation above would actually be broken)? The AIX boxen I have
> access to are all down at the moment.

Maybe Gary can check for us... Gary, what does the declaration for struct sockaddr_in look like in your AIX header file?

-brandon

Gary V. Vaughan· Apr 25, 2010, 08:37 UTC · re: Brandon Casey · lore

Re: [PATCH] daemon.c: avoid accessing ss_family member of struct sockaddr_storage

The git@mlists... address is the one subscribed to this list, to make it easy for us to filter list messages into shared folders. Because we manage so many packages, one or other of us will drop in and out of contact on the relevant lists depending what package we happen to be working on.

Anyway, you can always put a post directly in my INBOX by Cc:ing gary@thewrittenword.com and/or gary@gnu.org if you'd like to be sure that I will read something. :)

On Mon, Mar 15, 2010 at 04:42:57PM -0500, Brandon Casey wrote:

Show 21 quoted lines

> I expect that the layout of the sockaddr_* family of structures will
> follow the layout of struct sockaddr, otherwise they wouldn't be
> compatible.
> 
> In other words, I think that if struct sockaddr looks like this:
> 
>   struct sockaddr {
>         uchar_t         sa_len;         /* total length */
>         sa_family_t     sa_family;      /* address family */
>         char            sa_data[14];    /* actually longer; address value */
>   };
> 
> then somewhere else, struct sockaddr_in looks like this:
> 
>   struct sockaddr_in {
>         uchar_t         sin_len;
>         sin_family_t    sin_family;
>         sin_port;
>         sin_addr;
>         ...
>   };

Show 8 quoted lines

> On 03/15/2010 04:29 PM, Jeff King wrote:
> > Or am I wrong in assuming that, and on AIX sockaddr_in actually has
> > sa_len at the front, so casting to sockaddr does the right thing (and my
> > recommendation above would actually be broken)? The AIX boxen I have
> > access to are all down at the moment.
> 
> Maybe Gary can check for us... Gary, what does the declaration for
> struct sockaddr_in look like in your AIX header file?

/usr/include/netinet/in.h excerpt:

/*
 * Socket address, internet style.
 */
struct sockaddr_in {
        uchar_t        sin_len;
        sa_family_t    sin_family;
        in_port_t      sin_port;
        struct in_addr sin_addr;
        uchar_t        sin_zero[8];
};

Cheers,

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

Martin Storsjö· Mar 15, 2010, 21:37 UTC · re: Brandon Casey · lore

Re: [PATCH] daemon.c: avoid accessing ss_family member of struct sockaddr_storage

On Mon, 15 Mar 2010, Brandon Casey wrote:

Show 19 quoted lines

> diff --git a/daemon.c b/daemon.c
> index 3769b6f..8a52fdc 100644
> --- a/daemon.c
> +++ b/daemon.c
> @@ -590,9 +590,11 @@ static int execute(struct sockaddr *addr)
>  static int addrcmp(const struct sockaddr_storage *s1,
>      const struct sockaddr_storage *s2)
>  {
> -	if (s1->ss_family != s2->ss_family)
> -		return s1->ss_family - s2->ss_family;
> -	if (s1->ss_family == AF_INET)
> +	if (((const struct sockaddr*) s1)->sa_family !=
> +	    ((const struct sockaddr*) s2)->sa_family)
> +		return ((const struct sockaddr*) s1)->sa_family -
> +		       ((const struct sockaddr*) s2)->sa_family;
> +	if (((const struct sockaddr*) s1)->sa_family == AF_INET)
>  		return memcmp(&((struct sockaddr_in *)s1)->sin_addr,
>  		    &((struct sockaddr_in *)s2)->sin_addr,
>  		    sizeof(struct in_addr));

Coming to think about it, would it simplify the code even more if the function were to take a const struct sockaddr* as a parameter instead? That would, on the other hand, require more casts where it's called, though...

// Martin

Brandon Casey· Mar 15, 2010, 22:10 UTC · re: Martin Storsjö · lore

[PATCH v2] daemon.c: avoid accessing ss_family member of struct sockaddr_storage

From: Brandon Casey <drafnel@gmail.com>

Since any sockaddr_* structure can be cast to a struct sockaddr and have its sa_family member read, do so here to workaround this issue.

Thanks to Martin Storsjö for pointing out the fix, and Gary Vaughan for drawing attention to the issue.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---

On 03/15/2010 04:37 PM, Martin Storsjö wrote:

> Coming to think about it, would it simplify the code even more if the 
> function were to take a const struct sockaddr* as a parameter instead? 
> That would, on the other hand, require more casts where it's called, 
> though...

How about this.

-brandon

 daemon.c |   11 +++++++----
 1 files changed, 7 insertions(+), 4 deletions(-)

Show changes to daemon.c +7 −4

diff --git a/daemon.c b/daemon.c
index 3769b6f..2e6766f 100644
--- a/daemon.c
+++ b/daemon.c
@@ -590,14 +590,17 @@ static int execute(struct sockaddr *addr)
 static int addrcmp(const struct sockaddr_storage *s1,
     const struct sockaddr_storage *s2)
 {
-	if (s1->ss_family != s2->ss_family)
-		return s1->ss_family - s2->ss_family;
-	if (s1->ss_family == AF_INET)
+	const struct sockaddr *sa1 = (const struct sockaddr*) s1;
+	const struct sockaddr *sa2 = (const struct sockaddr*) s2;
+
+	if (sa1->sa_family != sa2->sa_family)
+		return sa1->sa_family - sa2->sa_family;
+	if (sa1->sa_family == AF_INET)
 		return memcmp(&((struct sockaddr_in *)s1)->sin_addr,
 		    &((struct sockaddr_in *)s2)->sin_addr,
 		    sizeof(struct in_addr));
 #ifndef NO_IPV6
-	if (s1->ss_family == AF_INET6)
+	if (sa1->sa_family == AF_INET6)
 		return memcmp(&((struct sockaddr_in6 *)s1)->sin6_addr,
 		    &((struct sockaddr_in6 *)s2)->sin6_addr,
 		    sizeof(struct in6_addr));

-- 
1.6.6.2

Martin Storsjö· Mar 16, 2010, 07:52 UTC · re: Brandon Casey · lore

Re: [PATCH v2] daemon.c: avoid accessing ss_family member of struct sockaddr_storage

On Mon, 15 Mar 2010, Brandon Casey wrote:

Show 7 quoted lines

> On 03/15/2010 04:37 PM, Martin Storsjö wrote:
> > Coming to think about it, would it simplify the code even more if the 
> > function were to take a const struct sockaddr* as a parameter instead? 
> > That would, on the other hand, require more casts where it's called, 
> > though...
> 
> How about this.

Yes, this looks neat!

Acked-by: Martin Storsjö <martin@martin.st>

// Martin

Gary V. Vaughan· Apr 25, 2010, 08:36 UTC · re: Martin Storsjö · lore

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

Hi Martin,

On Fri, Mar 12, 2010 at 09:24:01AM +0200, Martin Storsj? wrote:

Show 22 quoted lines

> 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)

Martin Storsjö· Apr 25, 2010, 19:05 UTC · re: Gary V. Vaughan · lore

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

Hi Gary,

On Sun, 25 Apr 2010, Gary V. Vaughan wrote:

Show 12 quoted lines

> 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. :-)

// Martin

Gary V. Vaughan· Apr 26, 2010, 16:55 UTC · re: Martin Storsjö · lore

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

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)

Jeff King· Mar 11, 2010, 22:27 UTC · re: Gary V. Vaughan · lore

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

On Thu, Mar 11, 2010 at 04:37:15PM +0000, Gary V. Vaughan wrote:

> Actually, the test for setting NO_IPV6 at configure time is still
> too optimistic and I have to manually pass '-DNO_IPV6' in CPPFLAGS
> at build time on aix-5.2.0.0 and earlier, and irix-6.5 and older
> for them to pick up the right branch.

Are you running 'configure' or just 'make'? If the latter, then the defaults for each platform are defined in the Makefile (e.g., see around line 790 of the Makefile where we turn off IPv6 for Solaris 2.7, but not 2.8). Patches to tweak the defaults for obscure platforms are welcome.

Also, now that I look at that, we seem to already have a NO_SOCKADDR_STORAGE flag that handles this case? Does setting that fix your problem without this patch?

-Peff

Brandon Casey· Mar 11, 2010, 23:57 UTC · re: Jeff King · lore

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

On 03/11/2010 04:27 PM, Jeff King wrote:

Show 15 quoted lines

> On Thu, Mar 11, 2010 at 04:37:15PM +0000, Gary V. Vaughan wrote:
> 
>> Actually, the test for setting NO_IPV6 at configure time is still
>> too optimistic and I have to manually pass '-DNO_IPV6' in CPPFLAGS
>> at build time on aix-5.2.0.0 and earlier, and irix-6.5 and older
>> for them to pick up the right branch.
> 
> Are you running 'configure' or just 'make'? If the latter, then the
> defaults for each platform are defined in the Makefile (e.g., see around
> line 790 of the Makefile where we turn off IPv6 for Solaris 2.7, but not
> 2.8). Patches to tweak the defaults for obscure platforms are welcome.
> 
> Also, now that I look at that, we seem to already have a
> NO_SOCKADDR_STORAGE flag that handles this case? Does setting that fix
> your problem without this patch?

NO_SOCKADDR_STORAGE is already set for Solaris 7, and still daemon.c can not be compiled since ss_family started being used, I think in 15515b73.

I should probably speak up when things break, but I tend to remain silent if I don't have the time to investigate.

-brandon