On Sat, Mar 9, 2013 at 6:23 AM, Edward Z. Yang <ezy...@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 <marlo...@gmail.com> > Date: Thu Feb 14 08:46:55 2013 +0000 > > Separate StablePtr and StableName tables (#7674) > > To improve performance of StablePtr. > > Cheers, > Edward _______________________________________________ FFI mailing list FFI@haskell.org http://www.haskell.org/mailman/listinfo/ffi