Foreign.StablePtr: nullPtr & double-free questions.
remi.turk at gmail.com
Wed Mar 13 21:09:18 CET 2013
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
> 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
As a bit of context, I'm working on a small library for working with
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
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;
Thanks, I'll just have to wait for a little while longer until 7.8 then :)
> 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.
More information about the Glasgow-haskell-users