Foreign.StablePtr: nullPtr & double-free questions.

[Remi Turk]

On Sat, Mar 9, 2013 at 6:23 AM, Edward Z. Yang <ezyang at mit.edu> 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 <marlowsd at gmail.com>
>     Date:   Thu Feb 14 08:46:55 2013 +0000
>
>         Separate StablePtr and StableName tables (#7674)
>
>         To improve performance of StablePtr.
>
> Cheers,
> Edward