ANN: H98 FFI Addendum 1.0, Release Candidate 7
alastair at reid-consulting-uk.ltd.uk
Thu Sep 26 11:50:25 EDT 2002
> We have four alternatives:
> (1) We leave everything as it is. If you want malloc-type storage
> that you can free in a finaliser, you need to write your own
> interface to C's malloc() and free().
I think this approach misses the reason we provide MarshalAlloc in the
> (2) We commit to using C's storage manager in Haskell's malloc
> routines. Then, C's free() can be used to free storage allocated
> with Haskell's malloc routines. (Whether we already provide a
> foreign import declaration to access &free from Haskell or leave
> that to the application is a minor detail.)
It seems tidier not to do this.
[Actually, I'd be tempted to strengthen the 'this is not C' feel of
the library by renaming malloc/free, dropping realloc, making the size
an explicit arguwent to free, etc. But any benefit from doing this
would be small so I'll resist this temptation.]
> (3) We provide a value
> finalizerFree :: FunPtr (Ptr a -> IO ())
> that frees storage allocated with Haskell's malloc routines
> without any guarantee that this coincides with C's free().
I think this is the best bet. (And it happens to be what Ross has
just implemented for Hugs.)
> (4) We add to the C land interface of the FFI a function
> void hs_free (void *);
> that behaves like MarshalAlloc.free, but can be called from a
> finalizer. (One can import this with &hs_free.)
This seems reasonable too. Kinda feels as though we'll end up doing
this eventually if we don't do it now.
> (Although, (4) suggests to also provide hs_malloc() and
Again, I suspect we'd end up doing these eventually if we don't do
More information about the FFI