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

["scc at mozilla 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



------- Additional Comments From scc at mozilla dot org  2003-07-09 16:20 -------
Howdy.  I'm the original author of the evil code in question :-)  Just checking
in to say I understand and appreciate the analysis.  The problem will be
extremely hard to fix within Mozilla in any `correct' way.  There are a couple
of different paths that will stop the symptoms from hurting the users at run-time.

I want to follow up to dbaron's earlier comment as well.

The purpose of |nsCOMPtr| is to provide sugar and glue to a clone of COM. 
Originally, |nsCOMPtr| was designed as a (almost) drop in replacement for raw
pointers to these reference counted COM objects.  The XPCOM inventors at the
time strongly resisted the introduction of a smart pointer class on the grounds
that it wasn't needed, that it couldn't work, that it would be a waste of space
and processing power, and that templates were broken in general.  The design had
to fit within the XPCOM rules without forcing itself on anyone.  That led to the
the primary hitch.  XPCOM functions that return pointers do so by assigning into
a |T**| result parameter.  This direct assignment interfered with any attempt to
manage refcounts automatically.  The answer was the ugly (and it turns out,
illegal) |getter_AddRefs( nsCOMPtr& )|, which |Releases| the current referent,
if any, and then provides a |T**| as expected by the called function for
assignment of the result.

This machinery allowed the same functions to be called with either a |T*| or an
|nsCOMPtr| in which to return their answer.

|nsCOMPtr|s began to dominate the code base because the people who didn't use
them pretty much always had leaks.  The people who did use them had far fewer. 
Had XPCOM's originators been more open minded about C++, we could have just
legislated that XPCOM object results are always returned through |nsCOMPtr&|s,
and no aliasing problem would exist; the |getter_AddRefs| glue could all be
thrown away.  I would like nothing more.  Such a change now would be very large.
 Not impossible, but certainly daunting.

Just a note of history to show how we got here, and to mention in passing that I
found nothing at which to take offense in any of the analyses and comments
above.  In fact, exactly the opposite: I really appreciate how deeply you guys
dug into the problem.  I hope I can come up with an answer that isn't just
another work-around on top of functionality that is, itself, a work-around.