It's hard to appreciate how good Rustls is at avoiding UaF since UaF avoidance is taken for granted in idiomatic Rust code. Tiny things like `#[must_use]` are small but help avoid big failures. Our friends doing concurrency & malloc/free in C are still struggling w/ the basics.
Like, for example in C++ the “this” pointer has to be a raw (non-RC’d) pointer. The language is hardwired to that.
-
-
The raw reference is perfectly safe as long as you know something further up the call stack has a refcounted reference on it. Need to ensure that happens when entering DOM code.
-
Well, not if it’s, say, a reference to the inside of a std::vector that can be resized.
-
(As I recall we’ve had several vulns due to exactly this.)
-
It’s an example of why this problem is so annoying: C++ wants you to use std::vector (just like Rust wants you to use Vec) but in a GC’d world you just created a landmine that can easily blow up in your face.
-
What's wrong with the Oilpan approach? (Honest question. I don't understand the limitations of Oilpan as they don't seem to be documented.)
-
In particular, I think one aspect of the Oilpan approach is "Don't use `Vec` or `std::vector`; you must use the Oilpan counterpart."
-
Same with Servo. That’s the ergonomic tax I was talking about though: I want something automatic that lets you write regular old Rust or C++, not weird-Servo-DOM-flavored Rust. I may not ever get what I want, but it doesn’t stop me from wanting it :)
End of conversation
New conversation -
-
-
It’s not a question of how to do it—it’s a trivial problem theoretically. It’s how to do it in a way that is ergonomic enough to scale up to a big DOM team.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.