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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html