If we comprehensively deploy smart pointers in place of raw pointers and manual 
memory management, then yes.

The render tree does have places where non-owning references are held, and 
these can be some of the biggest security risks. One notable example is the 
m_floats member in RenderInlineBox. Cleaning these up has historically depended 
on being really careful about teardown order.

To get rid of those without use of refcounting, we'll likely need a weak 
pointer scheme of some kind to go along with RenderPtr.

Regards,
Maciej

On Dec 31, 2013, at 11:53 AM, Ryosuke Niwa <rn...@webkit.org> wrote:

> 
> On Tuesday, December 31, 2013, Ryosuke Niwa wrote:
> Nice!  Does this also make render objects less dangerous? (For security)
> 
> On Monday, December 30, 2013, Andreas Kling wrote:
> Sup WebKittens,
> 
> I’ve just added a “RenderPtr" smart pointer to the rendering code and am in 
> the process of switching code from using raw pointers to this.
> 
> Check out the code here: <https://trac.webkit.org/r161115> (note that I’ve 
> since renamed createRenderObject to createRenderer per Antti’s suggestion.)
> 
> It’s basically a clone of OwnPtr that destroys the pointee by calling 
> destroy() on it. This is because RenderObjects currently has a virtual 
> willBeDestroyed() that may depend on still being inside the tree when it 
> executes. I’d like to simplify this eventually, and switch over to 
> std::unique_ptr, but that will require some spooky changes to basic tree 
> operations so I’m deferring it for now.
> 
> Cheers and happy new year,
> Kling
> 
> 
> -- 
> Ryosuke Niwa
> 
> 
> 
> 
> -- 
> - R. Niwa
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to