Marcin 'Qrczak' Kowalczyk mk167280 at
Tue Jan 2 09:33:47 EST 2001

On Tue, 2 Jan 2001, Simon Marlow wrote:

> > I would let freeHaskellFunPtr accept and ignore nullFunPtr, since I
> > once had to write
> >     when (ptr /= nullFunPtr) $ freeHaskellFunPtr ptr
> > and it can be seen as consistent with free.
> This makes sense if nullFunPtr is really a valid value for a FunPtr.
> The FFI spec doesn't say anything about f.e.d. functions possibly
> returning nullFunPtr.

They don't return nullFunPtr. My case was seting in a C struct a function
pointer made by f.e.d. or a null function pointer, for a C interface which
takes an optional user function (db3). Later the function pointer must be
freed if it was set, and there is nothing to be freed if its absence was
marked by nullFunPtr.

Null function pointers are a non-portable concept - ANSI C does not have
them, only null data pointers. But many existing C interfaces use them,
and even the ability to cast between data pointers and function pointers
is described as a common non-standard extension in ISO/ANSI C99.

Marcin 'Qrczak' Kowalczyk

More information about the FFI mailing list