From: Brandon Casey Date: Mon, 15 Mar 2010 21:42:57 GMT Subject: Re: [PATCH] daemon.c: avoid accessing ss_family member of struct sockaddr_storage Message-ID: In-Reply-To: <20100315212915.GB25342@coredump.intra.peff.net> 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