freeHaskellFunctionPtr

[Marcin 'Qrczak' Kowalczyk]

Tue, 02 Jan 2001 19:40:11 +1100, Manuel M. T. Chakravarty <chak at cse.unsw.edu.au> pisze:

> PS: It could be argued that `Ptr ()' can always be used
>     instead of `Addr' and that therefore we should do away
>     with `Addr' altogether.  Opinions?

I agree that Addr uses should be replaced by Ptr and FunPtr
(well, I thought it was obvious!).

Since Addr is used much in ghc and nhc and probably external libraries,
we will live with both for some time, perhaps long, and it's not
necessary to convert everything in a hurry. But I would not care if
some functionality is provided in Ptr flavor only, especially as it's
easy to convert in both directions.

newForeignObj has been converted to Ptr, but since ForeignObjs
themselves were later replaced with ForeignPtrs, it makes sense to
let newForeignObj use Addr again as in previous released versions of
ghc. For withForeignObj it could be done for consistency too (it's
new so it does not really matter).

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.

It could be called freeHsFunPtr instead.

I asked once and got no response: in ghc's implementation, should it
really be foreign imported unsafe?

On IA-64 C function pointers are AFAIK twice as big as data pointers
(16 bytes!), to hold a global data pointer associated with the module
the function came from, which is a part of a model of dynamically
linked libraries. I don't know what ghc is going to do with it - it
uses function pointers internally a lot! It also means that FunPtr
will no longer be represented the same as Ptr on IA-64.

-- 
 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTÊPCZA
QRCZAK