Re: Everyone working on the C side might want to read this article...

[Bruce Korb]

Rob Browning wrote:
> 
> Rob Browning <address@hidden> writes:
> 
> > The following article explains gcc changes that may be behind at least
> > some of our recent set of bugs:
> >
> >   http://www.ddj.com/documents/s=880/ddj0010d/0010d.htm
> 
> So does anyone have thoughts about how we should approach this issue?
> How common do we think these type aliasing problems might be in our
> code, and if we do have problems, can we just fix each offending bit
> of code with temp assignments or other "disambiguating" statements, or
> is there some higher level way we might be able to address the issue
> (i.e. could a union help here, something else?).

The default optimization is sufficient for many of the aliasing
problems.  If you compile with the GCC 3.3 branch -Wall will trigger
some extra aliasing-related warnings.  Examine the warnings carefully.
Remember that just because it didn't warn doesn't mean there isn't
a problem.  However, the warnings do actually cover most of the common
ways aliasing breaks code.  WRT how to fix, there are several solutions:

1.  you can go the way of the kernel and -fno-strict-aliasing
2.  you can unionize the pointer types
3.  you can use the "I can point to anything" pointer types
    viz., char* and void*.

A sure fire test, once you've discovered a problem, is to
try rebuilding with -fno-strict-aliasing and see if the
problem goes away.