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
