ANN: H98 FFI Addendum 1.0, Release Candidate 7

[Simon Marlow]

> > > 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