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

["kevin dot hendricks at sympatico dot ca" <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



------- Additional Comments From kevin dot hendricks at sympatico dot ca  2003-07-08 19:50 -------
Subject: Re:  [3.3/3.4 regression] mozilla-1.4 miscompiled

Hi,

> They chose a wicked code
> design involving evil constructs such as casting to void** and using
> reinterpret_cast. It is certainly not only my personal view that this
> obfuscated the code to a degree that none of us could easily see what
> was going on.

Since it is not my code, I completely agree with you!    ;-)
Give me a dumb pointer over a "smart pointer" any day.

I am a big fan of obviousness and really love C compared to C++
because I hate having anything done "implicitly" and anything
that impacts following the clear flow of the code (such as templates,
multiple inheritance, implicit constructors and destructors, etc)
gives me a headache.  That was why it took me so long to trim
down the testcase to something small, I could not figure out
why nsDerivedsafe and nsGetterType templates were being
passed around to begin with.

> It is not up to me to judge how this might affect the
> mozilla developers community.

Unfortunately, it is just not them.  Almost every major piece of
code I have played with closely (the JDK, OpenOffice.org, and
now Mozilla) seems to have problems.  I build all of OOo, the JDK,
and even Mozilla with -fno-strict-aliasing just to avoid having to track
down these problems.

> However, I think there are more pressing
> things to do in gcc than to invent ways to track the course pointers 
> take
> just to catch problems like this one. After all, it is not only time
> consuming to track down such bugs, but also to implement tracking them
> inside the compiler.

I am sure there are other more important issues but the
improvements in the strictness of the C++ parser in gcc 3.3
plus heavy use of -Wall has certainly helped OpenOffice.org
find and fix serious bugs.  So having a similar warning for aliasing
violations really would help improve code in the wild.

> Putting it somewhat bluntly (please take this with a grain of salt):
> If you choose to shoot yourself in the foot, gcc shouldn't interfere.

Agreed!  ... but it might be nice if it told you the gun was using 
teflon
coated steel jacketed shells when you thought your gun was actually
loaded with blanks.


----
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London Ontario, CANADA  N6A 3K7
khendricks@ivey.uwo.ca