Re: ANN: H98 FFI Addendum 1.0, Release Candidate 7
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. -- Alastair
Alastair Reid <alastair@reid-consulting-uk.ltd.uk> wrote,
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. Cheers, Manuel
participants (2)
-
Alastair Reid -
Manuel M T Chakravarty