[Bug c++/11376] [3.3/3.4 regression] mozilla-1.4 miscompiled

["dbaron at dbaron dot org" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11376


dbaron at dbaron dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dbaron at dbaron dot org


------- Additional Comments From dbaron at dbaron dot org  2003-07-08 23:26 -------
In response to comment 32:
> It is only if you try to outsmart C/C++'s type system that you
> are in danger. But I don't see why people should do that, templates offer them
> plenty of ways to always stay on the safe side, and the compiler will tell
> you about illegal casts -- unless you use void* and reinterpret_cast.

Just to offer a little perspective from the Mozilla side of things, I think
there are two main reasons why people working on Mozilla don't do as you think
they should:

 1. Portability to compilers that exist now and that we want to support
generally ends up winning over portability to compilers that don't exist. 
Programmers generally don't understand all the rules (especially cases where
behavior is undefined) of the language standards.  Until late 2001, Mozilla
supported gcc 2.7.2.3 (because it was, until then, the only way to use Purify on
any Unix platform (Solaris), and valgrind didn't exist), which made using
templates very difficult.  Some of the other compilers that we still support
also cause problems, so introducing any new templates into Mozilla still
requires extensive testing and takes much more work than alternatives.

(This is even more true for many web standards.  While http://gcc.gnu.org/ is
valid HTML (I'm impressed), it's still violating a "should not"-level
requirement of the HTML specification since it uses tables for something other
than the presentation of tabular data.  Not that I blame you, since tables
remain the only portable way of achieving many types of presentation.)

 2. Compilers often don't optimize code the way the programmer wants.  (My most
recent experience with this was
http://bugzilla.mozilla.org/show_bug.cgi?id=206682#c25 , and I've been meaning
to file a gcc bug.)  nsCOMPtr is very heavily used in the Mozilla codebase and
has been hand-optimized for a number of different compilers.  (You miss all the
|#ifdef|s by looking at the preprocessor output.)  In this case, the aliasing
rules are being broken because of hand-optimization that I suspect was to
improve the size of the generated code (although one that's being used on all
platforms on which it compiles, which may not be necessary).


Don't take any of that to mean that we don't want to fix our aliasing bugs.  We do.