> > > RC 7 of the FFI Addendum is now available from > > > > In adding mallocForeignPtr and friends to Hugs, I found > that I needed > > the address of free to pass as a parameter. > > > > There's no suitable way to generate &free from > MarshalAlloc.free (the > > obvious use of a Haskell wrapper would break the whole > reason for the > > recent change to ForeignPtrs). > > > > Could we add &free to the export list of MarshalAlloc? > > > > foreign import ccall unsafe "stdlib.h &free" ptr_free :: > FunPtr (Ptr a -> IO ()) > > > > I am currently using 'ptr_free' as the Haskell name for this pointer > > but I expect that a better name could be found with little effort. > > So far, we never explicitly say (I believe) that `malloc' > corresponds to C's `malloc()'; ie, that C's `free()' (and > hence, `ptr_free') may actually be used to free storage that > has been allocated by `malloc'. > > We might define the CAF > > cfree :: FunPtr (Ptr a -> IO ()) > > as a pointer to a C function that free's storage allocated > with `malloc' from C without entering Haskell land and > explicitly note that this is useful as a finalizer. > > The construction still seems pretty awkward to me. I hope > the change to ForeignPtr doesn't entail any more nasty > suprises like this.
... 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. A separate issue is whether MarshalAlloc.malloc *should* be specified as being an interface to C's malloc(). I hadn't noticed that it currently wasn't. I don't think I have any code that relies on it, and I can't think of any strong arguments one way or the other, apart from the fact that MarshalAlloc is not part of the C-specific marshalling library. Cheers, Simon _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi