[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-06-30 13:40 -------
Subject: Re:  [3.3/3.4 regression] mozilla-1.4 miscompiled

Hi,

> - Are the specializations of nsCOMPtr<> and nsGetterAddRefs<> really
> necessary to trigger the bug? They look to me just manual replacements of
> the template argument. If the are needed, did you try removing the
> definition of the general templates?

I believe so yes.  I did try removing the general templates but ran into 
problems trying to compile this.  All of my attempts to recreate this problem 
with a general type did not succeed.

The nsCOMPtr template is some sort of smart pointer used in libxpcom that I am 
not sure I understand.  The specialization seems to be on handling the 
nsISupports xpcom interface types.  The real test problem is huge and 
involved numerous libraries.  I just tried to help out by narrowing down the 
problem to a standalone testcase and I had to bascially cut and paste the  
nsCOMPtr templates in order to see the problem at all.

I was afraid if I did too much hacking away of that template class and the 
getter routines (since I did not udnerstand them well)  I would introduce a 
new problem.


> - Are all the member functions of the templates really used by the program?

I am simply not sure.   I will try to hack more away when I have more time 
later today but I was afraid to do so until I understood what was actaully 
going on and how the variaous templates interact.  This is pretty much out of 
my league since I just dabble in C++.  My single goal was to recreate the 
problem in a standalone test case  and try not to introduce any new problems 
when doing so.

> - This:
>
>       nsDerivedSafe<T>*
>       get() const
>         {
>           return reinterpret_cast< nsDerivedSafe<T>* >(mRawPtr);
>         }
> is not typesafe and generates undefined behaviour if you do anything with
> the returned pointer BUT casting it back to its original type
> (nsISupports*).

Kevin