Re: Foreign.StablePtr: nullPtr & double-free questions.

On Sat, Mar 9, 2013 at 6:23 AM, Edward Z. Yang wrote:

Excerpts from Remi Turk's message of Fri Mar 08 18:28:56 -0800 2013:

...

1) The documentation suggests, but does not explicitly state, that castStablePtrToPtr `liftM` newStablePtr x will never yield a nullPtr. Is this guaranteed to be the case or not? It would conveniently allow me to store a Maybe "for free", using nullPtr for Nothing, but I am hesitant about relying on something that isn't actually guaranteed by the documentation.

No, you cannot assume that. In fact, stable pointer zero is base_GHCziTopHandler_runIO_info:

[...]

Regardless, you don't want to do that anyway, because stable pointers have a bit of overhead.

Thanks for your quick reply. Could you elaborate on what "a bit of overhead" means? As a bit of context, I'm working on a small library for working with (im)mutable extendable tuples/records based on Storable and ForeignPtr, and I'm using StablePtr's as back-references to Haskell-land. Would you expect StablePtr's to have serious performance implications in such a scenario compared to, say, an IORef?

...

2) If I read the documentation correctly, when using StablePtr it is actually quite difficult to avoid undefined behaviour, at least in GHC(i). In particular, a double-free on a StablePtr yields undefined behaviour. However, when called twice on the same value, newStablePtr yields the same StablePtr in GHC(i). [...]

I think this bug was inadvertently fixed in the latest version of GHC; see:

Thanks, I'll just have to wait for a little while longer until 7.8 then :) Cheers, Remi

commit 7e7a4e4d7e9e84b2c57d3d55e372e738b5f8dbf5 Author: Simon Marlow Date: Thu Feb 14 08:46:55 2013 +0000

Separate StablePtr and StableName tables (#7674)

To improve performance of StablePtr.

Cheers, Edward