Aliasing violations in gnu_java_nio_VMChannel.c
|
View:
New views
5 Messages
—
Rating Filter:
Alert me
|
 |
Aliasing violations in gnu_java_nio_VMChannel.c
by Andrew Haley
::
Rate this Message:
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. |
|
|
Re: Aliasing violations in gnu_java_nio_VMChannel.c
by gnu_andrew
::
Rate this Message:
2009/10/22 Andrew Haley <aph@...>:
> 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. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 |
|
|
Re: Aliasing violations in gnu_java_nio_VMChannel.c
by Andrew Haley
::
Rate this Message:
Andrew John Hughes wrote:
> 2009/10/22 Andrew Haley <aph@...>: >> 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. |
|
|
Re: Aliasing violations in gnu_java_nio_VMChannel.c
by gnu_andrew
::
Rate this Message:
2009/10/23 Andrew Haley <aph@...>:
> Andrew John Hughes wrote: >> 2009/10/22 Andrew Haley <aph@...>: >>> 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. > Why not just amend the CFLAGS in the local Makefile.am for cpnet? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 |
|
|
Re: Aliasing violations in gnu_java_nio_VMChannel.c
by Andrew Haley
::
Rate this Message:
Andrew John Hughes wrote:
> 2009/10/23 Andrew Haley <aph@...>: >> Andrew John Hughes wrote: >>> 2009/10/22 Andrew Haley <aph@...>: >>>> 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? > > Why not just amend the CFLAGS in the local Makefile.am for cpnet? Sure. It won't make much difference, I suspect. Andrew. |
| Free embeddable forum powered by Nabble | Forum Help |
