Heap representation evil

Brandon Moore brandonm at yahoo-inc.com
Mon Oct 23 21:43:26 EDT 2006


Thinking to take advantage of fortuitous heap layout of some Haskell 
values for interfacing with C, I've written the following function:

addressOf :: a -> Ptr ()
addressOf x = x `seq` unsafeCoerce# (Box x)
data Box x = Box x

For example,

data A = A {-# UNPACK #-} !(Ptr Word8) {-# UNPACK #-} !CInt

main = let a = A nullPtr 12
           p = addressOf a `plusPtr` 4
     in do x <- peek p :: IO Int
           y <- peek p :: IO Int
           print (x, y)
prints
(0, 12)

One thing I don't understand is that this fails if I use Just
rather than inventing my box type. I suppose the info table for
Just is set up to support a vectored return for pattern matching
on Maybe? (the commentary isn't very clear here. The section
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/HaskellExecution#ReturnConvention
says, in full:
"Return Convention
 Direct Returns
 Vectored Returns"
)

The reason I'm messing about with this stuff is that I'm pretty sure 
passing p to C code would give a usable pointer to
struct a {char *; int;};

Obviously my plot will be spoiled if the GC comes along and relocates 
the value while C code is trying to use it.

Are there any other pitfalls with this approach?

A different and in all likelihood saner approach is building up more 
tools for manipulating pointers to C data from Haskell, perhaps along 
the lines of cmucl's support for "Alien Objects".
http://www.math.sunysb.edu/~sorin/online-docs/cmucl/aliens.html

The main reason to even think about touching the heap representation of 
Haskell objects is so that the values can be manipulated by pure code,
pattern matched, etc.

Brandon


More information about the Glasgow-haskell-users mailing list