On 2014-12-22 4:10 PM, Jeff Muizelaar wrote:
We were talking about this problem and it was a bunch of work to figure out the
conclusion so I decided to write a summary:
Replacing already_AddRefed with nsRefPtr causes allows two new things:
nsRefPtr<T> getT();
1. T* p = getT(); // this is unsafe because the destructor runs immediately and
p is left dangling
2. foo(getT()); // this is safe
Possible solutions would be to:
- remove implicit conversions to T*
Perhaps we should consider doing this.
- add operator T* explicit and operator T* && = delete // this will be
available in GCC 4.8.1 and MSVC 2014 Nov CTP
-Jeff
On Aug 14, 2014, at 10:21 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote:
On Thu, Aug 14, 2014 at 10:02 AM, Aryeh Gregor <a...@aryeh.name> wrote:
On Thu, Aug 14, 2014 at 12:00 PM, Neil <n...@parkwaycc.co.uk> wrote:
Well there's your problem: GetWSBoundingParent doesn't need to own the
nodes
it works on.
Editing code is ancient, poorly maintained, and not
performance-sensitive, so personally, I don't ever use raw pointers as
local variables in editor/. Better to not have to rely on manual
review to prevent use-after-free bugs. I am aware of at least one
sec-critical bug in editor that resulted from non-use of nsCOMPtr that
slipped through review when someone was rewriting editing code.
In this case, I seem to remember I wanted to change it to return a raw
pointer instead of already_AddRefed, but IIRC, Ehsan said not to
(although I can't find that anywhere, so maybe I made it up).
I don't remember either!
--
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
