On 2014-12-23 5:30 PM, Eric Rescorla wrote:
On Tue, Dec 23, 2014 at 2:19 PM, Ehsan Akhgari <[email protected] <mailto:[email protected]>> wrote:On 2014-12-23 5:13 PM, Eric Rescorla wrote: On Tue, Dec 23, 2014 at 2:07 PM, L. David Baron <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> wrote: On Tuesday 2014-12-23 14:03 -0800, Eric Rescorla wrote: > This may be a much longer argument, but I'm not convinced that > sacrificing what would otherwise be good programming practice > (never unboxing your pointers) at the altar of performance is a good > idea. Why do you think never unboxing pointers is a good programming practice? Because it allows/encourages mixed ownership regimes between reference counting (or single ownership) and explicit management. Note that I'm not saying that there's never a time for unboxing, but it should be done carefully not routinely. I think there is a different way of looking at things. When you pass a conceptual pointer value to a function, sometimes you want an ownership change to happen, and at other times you just want the callee to use the pointer (perhaps to call functions on it, for example) without changing the ownership. I think unboxing the pointer for the latter case is perfectly fine, as long as enforce that the ownership on the caller side remains valid for the duration of the call, and that the callee doesn't do something that changes the ownership behind the scenes (the latter is more challenging. Well, I certainly agree it's more challenging, since nothing stops the callee from simple assigning the raw pointer to some location that outlives the function call.
That's actually pretty easy to detect and disallow! Filed bug 1115175. > The idea behind requiring that pointers
remain boxed is to prevent that and/or to shine a light on places where it is possible because someone unboxed.
Right. And that's one solution but it's not the only one. I'm hoping to make our clang plugin much more aware of our ownership rules so that it can enforce a lot of them.
_______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
