Heap representation evil

[Simon Marlow]

Brandon Moore wrote:
> 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?

Yes, exactly right.

> (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"
 > )

Sorry, I haven't got around to writing that section yet!

> 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.

Yes.

> Are there any other pitfalls with this approach?

The GC pitfall not enough for you? :)  Well, future GHC versions might change 
the representation under your feet, since we don't consider the heap object 
representation to be stable, user-visible stuff.

Cheers,
	Simon