On Sun, Sep 22, 2002 at 02:54:44PM +1000, Manuel M T Chakravarty wrote:
Ross Paterson [EMAIL PROTECTED] wrote,
Alastair Reid [EMAIL PROTECTED] wrote:
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
Ross Paterson [EMAIL PROTECTED] wrote,
Alastair Reid [EMAIL PROTECTED] wrote:
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
Alastair Reid [EMAIL PROTECTED] wrote:
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.
Yes, you're
Alastair Reid [EMAIL PROTECTED] 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
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
... 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