Re: Aliasing violations in gnu_java_nio_VMChannel.c

Andrew Haley <[email protected]>
Newsgroups gmane.comp.java.classpath.devel
Message-ID <[email protected]>
Andrew John Hughes wrote:
> 2009/10/22 Andrew Haley <[email protected]>:
>> This:
>>
>>
>> #ifdef HAVE_GETPEERNAME
>> #ifdef HAVE_INET6
>>  struct sockaddr_in6 *addr6;
>>  struct sockaddr_in6 sock_storage;
>>  socklen_t socklen = sizeof (struct sockaddr_in6);
>> #else
>>  struct sockaddr_in sock_storage;
>>  socklen_t socklen = sizeof (struct sockaddr_in);
>> #endif /* HAVE_INET6 */
>>
>>  struct sockaddr *sockaddr = (struct sockaddr *) &sock_storage;
>>
>>
>> is clearly an aliasing violation: sock_storage is of type struct sockaddr_in6,
>> and *sockaddr is of type struct sockaddr.
>>
>> It would be easy enough to fix the code with a union, but I can't test it
>> because gcj doesn't use this code.  I could simply compile with
>> -fno-strict-aliasing.
>>
>> Thoughts?
>>
>> Andrew.
>>
>>
> 
> I posted a patch sometime ago to do exactly that (use a union), but
> received no response:
> 
> http://developer.classpath.org/pipermail/classpath-patches/2009-June/006341.html
> 
> It does need more testing than I've had chance to give it so far, I
> just haven't had time to do any more work on it.

I seriously wonder if it's worth the effort.  I just did this:

Index: configure.ac
===================================================================
RCS file: /sources/classpath/classpath/configure.ac,v
retrieving revision 1.244
diff -c -u -r1.244 configure.ac
--- configure.ac        6 Feb 2009 02:21:23 -0000       1.244
+++ configure.ac        23 Oct 2009 09:10:33 -0000
@@ -514,7 +514,7 @@
     dnl CFLAGS that are used for all native code.  We want to compile
     dnl everything with unwinder data so that backtrace() will always
     dnl work.
-    EXTRA_CFLAGS='-fexceptions -fasynchronous-unwind-tables'
+    EXTRA_CFLAGS='-fexceptions -fasynchronous-unwind-tables -fno-strict-aliasing'
     AC_SUBST(EXTRA_CFLAGS)

     dnl Strict warning flags which not every module uses.

which is a much safer change.  It will somewhat pessimize other native code,
that's true, but will that make any real difference to anyone these days?

Andrew.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.