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.
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
... 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
participants (2)
-
Alastair Reid -
Simon Marlow