ANN: H98 FFI Addendum 1.0, Release Candidate 7

[Ross Paterson]

On Sun, Sep 22, 2002 at 02:54:44PM +1000, Manuel M T Chakravarty wrote:
> Ross Paterson <ross at soi.city.ac.uk> wrote,
> 
> > Alastair Reid <alastair at reid-consulting-uk.ltd.uk> 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 trying to recover something that was lost with the change
> > to newForeignPtr.  Formerly one could allocate something with malloc
> > or mallocArray and add a finalizer that called free.  Now you can't,
> > except in the canned special case of mallocForeignPtr.  But there's
> > nothing similar for arrays, as required e.g. in Data.Array.Storable.
> 
> I think SimonM and Ross have a point here.  There isn't
> really anything gained from linking `MarshalAlloc.malloc' up
> with a C version of `MarshalAlloc.free'.  So, I think we
> should leave it as it is.

That wasn't what I was arguing.  Consider the following code from
Data.Array.Storable:

    newArray_ (l,u) = do
        a  <- mallocArray (rangeSize (l,u))
        fp <- newForeignPtr a (free a)
        return (StorableArray l u fp)

That's using the old type of newForeignPtr.  How can that be rewritten
using the new type, without Alastair's ptr_free?  I guess one could use
mallocForeignPtrBytes and duplicate the MarshalArray stuff, but that
seems ugly.

So Alastair's proposal gets back some of what was lost in the change of
newForeignPtr, though it's only a partial solution.  (It doesn't cover
the use in Text.Regex.Posix, for example.)