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* - 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
