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