Re: gcc-4 troubleshooting

[Fyodor <fyodor () insecure org>]

On Sun, Aug 28, 2005 at 04:52:38PM -0300, Duilio J. Protti wrote:
> Attached is a patch to configure.ac that take this into account. I have
> tested successfully with both gcc 3 and gcc 4 on FC3.

Thanks, Duilio.  I have applied this for the next version of Nmap.
While this works for now, a better approach might be to find all the
lines that apparently violate C99 alias rules and fix them.  Here is
an example that SoC student Paul Tarjan found (from tcpip.cc):

buf = (u8 *) safe_zalloc(bufsz);
[...]
ifr = (struct ifreq *) buf;
[...]
   for(; ifr && *((u8 *)ifr) && ((u8 *)ifr) < buf + ifc.ifc_len;
        ((*(char **)&ifr) += len ))

I don't know if it is technically legal or not, but gcc doesn't seem
to like it with -O2.  It is pretty gross anyway, and deserves to be
changed for that reason if no other.

Here is the gcc documentation for the strict-alias optimization:

http://gcc.gnu.org/onlinedocs/gcc-4.0.1/gcc/Optimize-Options.html#Optimize-Options

Apparently, they tried strict alias to an earlier gcc release years
ago, but so many programs broke that they relented.  But now it is
apparently back (with -O2).  The Linux kernel sets
-fno-strict-aliasing during compilation, as Linus himself disparages
the strict aliasing optimizations (back in '03) at:

http://seclists.org/lists/linux-kernel/2003/Feb/6182.html
http://seclists.org/lists/linux-kernel/2003/Feb/6449.html

Still, Nmap is a lot smaller and simpler than the Linux kernel and so
maybe we have a better shot and identifying and resolving the
underlying problems.  Allowing strict-aliasing may even help
performance slightly.  More importantly, I worry that other compilers
may adopt these optimizations and might not even offer a way to
disable them.

Cheers,
-F


_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev