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

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

[Gary V. Vaughan]

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

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)

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

[Martin Storsjö]

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

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

[Jeff King]

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

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

[Brandon Casey]

On 03/11/2010 04:27 PM, Jeff King wrote:
> 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

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

[Gary V. Vaughan]

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

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

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

[Martin Storsjö]

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

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

[Brandon Casey]

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

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

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

[Jeff King]

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?

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

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

[Martin Storsjö]

On Mon, 15 Mar 2010, Brandon Casey wrote:

> 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

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

[Martin Storsjö]

On Mon, 15 Mar 2010, Jeff King wrote:

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

> 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

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

[Brandon Casey]

On 03/15/2010 04:29 PM, Jeff King wrote:
> 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

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

[Brandon Casey]

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_STORAGE.

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

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

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

[Martin Storsjö]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 431 bytes --]

On Mon, 15 Mar 2010, Brandon Casey wrote:

> 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

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

[Gary V. Vaughan]

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)

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

[Gary V. Vaughan]

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:
> 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;
>         ...
>   };

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

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

[Martin Storsjö]

Hi Gary,

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

// Martin

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

[Gary V. Vaughan]

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

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