David Watson <bai...@users.sourceforge.net> added the comment: 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). ---------- keywords: +patch nosy: +baikie versions: +Python 3.3 Added file: http://bugs.python.org/file23186/socket-aliasing-sas2sa.diff _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8623> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
