For reference, the warnings are partially explained here:

http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-825

http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Warning-Options.html#index-Wstrict_002daliasing-337

I get these warnings with GCC (Ubuntu/Linaro 4.4.4-14ubuntu5)
4.4.5 [i386], plus an additional one from the new recvmsg() code.
I haven't tried GCC 4.5 or later, but as the docs imply, the
warnings will not appear in debugging builds.

I take it GCC is referring to C99 section 6.5, paragraphs 6 and 7
here, but I'm not sure exactly how much these are intended to
prohibit with regard to the (mis)use of unions, or how strictly
GCC actually enforces them.

The attached socket-aliasing-sas2sa.diff is enough to get rid of
the warnings with GCC 4.4.4 - it adds add a "struct sockaddr"
member to the sock_addr_t union type, changes the SAS2SA() macro
to take the address of this member instead of using a cast, and
modifies socket_gethostbyaddr() and socket_gethostbyname_ex() to
use SAS2SA() (sock_recvmsg_guts() already uses it).

Changing SAS2SA() also gets rid of most of the additional
warnings produced by the "aggressive" warning setting
-Wstrict-aliasing=2.  However, the gethostby* functions still
point to the union object with a pointer variable not matching
the type actually stored in it, which the GCC docs warn against.

To be more conservative, socket-aliasing-union-3.2.diff applies
on top to get rid of these pointers, and instead directly access
the union for each use other than providing a pointer argument to
a function.  socket-aliasing-union-recvmsg-3.3.diff does the same
for 3.3, and makes the complained-about line in
sock_recvmsg_guts() access the union directly as well.

One other consideration here is that the different sockaddr_*
struct types used are likely to come under the "common initial
sequence" rule for unions (C99 6.5.2.3, paragraph 5, or section
A8.3 of K&R 2nd ed.), which might make some more questionable
uses valid.  That said, technically POSIX appears to require only
that the s*_family members of the various sockaddr struct types
have the same offset and type, not that they form part of a
common initial sequence (s*_family need not be the first
structure member - the BSDs for instance place it second,
although it can still be part of a common initial sequence).