ANN: H98 FFI Addendum 1.0, Release Candidate 7
alastair at reid-consulting-uk.ltd.uk
Thu Sep 19 16:24:48 EDT 2002
> ... 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.
More information about the FFI