On 2014-12-23 5:30 PM, Eric Rescorla wrote:
On Tue, Dec 23, 2014 at 2:19 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com
<mailto:ehsan.akhg...@gmail.com>> wrote:
On 2014-12-23 5:13 PM, Eric Rescorla wrote:
On Tue, Dec 23, 2014 at 2:07 PM, L. David Baron
<dba...@dbaron.org <mailto:dba...@dbaron.org>
<mailto:dba...@dbaron.org <mailto:dba...@dbaron.org>>> 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
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform