On Fri, Dec 28, 2012 at 3:52 AM, Neil wrote:
> Jonas Sicking wrote:
>
>> There's nothing special about XPCOM objects here.
>>
>
> While this is clearly true, I still feel it's getting away from my original
> point, because I was trying to compare with nsCOMArray.
I guess my argument is: Sure, nsT
Jonas Sicking wrote:
There's nothing special about XPCOM objects here.
While this is clearly true, I still feel it's getting away from my
original point, because I was trying to compare with nsCOMArray.
--
Warning: May contain traces of nuts.
___
On Thu, Dec 27, 2012 at 1:56 PM, Neil wrote:
> Jonas Sicking wrote:
>
>> On Dec 18, 2012 4:15 AM, "Neil" wrote:
>>
>>>
>>> While investigating the possibility of switching nsCOMArray away from
>>> nsVoidArray it occurred to me that nsCOMArray takes steps to ensure internal
>>> consistency before
Jonas Sicking wrote:
On Dec 18, 2012 4:15 AM, "Neil" wrote:
While investigating the possibility of switching nsCOMArray away from
nsVoidArray it occurred to me that nsCOMArray takes steps to ensure internal
consistency before releasing removed elements; this is because it's potentially
p
On Dec 18, 2012 4:15 AM, "Neil" wrote:
>
> While investigating the possibility of switching nsCOMArray away from
nsVoidArray it occurred to me that nsCOMArray takes steps to ensure
internal consistency before releasing removed elements; this is because
it's potentially possible for Release() to in
While investigating the possibility of switching nsCOMArray away from
nsVoidArray it occurred to me that nsCOMArray takes steps to ensure
internal consistency before releasing removed elements; this is because
it's potentially possible for Release() to invoke arbitrary code; if
this code ends u
6 matches
Mail list logo