ANN: H98 FFI Addendum 1.0, Release Candidate 7

[Alastair Reid]

> ... maybe I'm being stupid, but I don't see what the problem is.
> Why can't mallocForeignPtr be implemented as:

>   mallocForeignPtrBytes size = do
>     r <- c_malloc (fromIntegral size)
>     newForeignPtr r ptr_c_free
> 
>   foreign import ccall unsafe "malloc"
>     c_malloc :: CInt -> Ptr a
>   foreign import ccall unsafe "&free" 
>     ptr_c_free :: ForeignPtr (Ptr a -> IO ())

> i.e. it's completely independent of MarshalAlloc.malloc.  If you
> happen to know that MarshalAlloc.malloc is the same as C's malloc,
> then you could use that instead, but you don't have to.

That's fine and, of course, it can be implemented that way.

I guess the issue is that if someone wanted to use MarshalAlloc.free
as a finalizer they would not be able to do so.  Since we don't
guarantee that MarshalAlloc.malloc is "stdio.h malloc", they couldn't
portably cons up a compatible &free.

The relevance to mallocForeignPtr and friends is only that I happened
to notice the problem while implementing them.

--
Alastair