On Tue, Aug 12, 2014 at 9:35 AM, Aryeh Gregor <a...@aryeh.name> wrote: > On Tue, Aug 12, 2014 at 6:46 PM, L. David Baron <dba...@dbaron.org> wrote: >> In these cases we document that it's likely safe for callers to do >> this by having those getters return raw pointers. Getters that >> require reference-counting return already_AddRefed. Thus the >> designer of the API makes a choice about whether the caller is >> required to reference-count the result. > > How is this code safe? > > nsIContent* child = node->GetFirstChild(); > // Do some stuff with child > > It compiles fine, but if any subsequent code causes the child to be > removed from its parent, it could get freed. In particular, this can > happen if anything indirectly triggers mutation observers, and I > distinctly remember a sec-critical bug caused by exactly that. > Reviewers already have to carefully scrutinize any use of such a local > variable. Does returning already_AddRefed really make such a > difference to the degree of review required? > > Put it this way -- if we had rvalue references available when > already_AddRefed was invented, would anyone have suggested making a > whole new class that's significantly more cumbersome to use just to > avoid making an inherently dangerous usage pattern (raw pointers to > refcounted variables) a little less dangerous? Or is this just status > quo bias? > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform
If that function returns already_AddRefed it forces the caller to root the return value which means you do not have to review as closely for use-after-free issues. We use raw pointers where we can because reference counting can be expensive, especially in tight loops. smaug can share some history here. - Kyle _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
