I propose to deprecate `freeHaskellFunctionPtr' in Foreign. Equivalent functionality is now available from `Ptr.freeHaskellFunPtr'. Normally, we have all `Ptr' functionality also in a variant for `Addr', but in this case, this doesn't make sense in my opinion. The reason is that `Addr' is there as a backup solution when `Ptr' doesn't fit. But if a `Addr' is used to represent a Haskell function pointer, I don't see a reason that `Ptr.FunPtr' could not have been taken. If there are no objections, I will deprecate `freeHaskellFunctionPtr' in `Foreign'. Cheers, Manuel 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?
Tue, 02 Jan 2001 19:40:11 +1100, Manuel M. T. Chakravarty <chak@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@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK
On 02-Jan-2001, Marcin 'Qrczak' Kowalczyk <qrczak@knm.org.pl> wrote:
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.
Are you sure about that? Are you sure function pointers aren't represented as ordinary pointers to a 16-byte block of memory that includes a code pointer and a data pointer? (I don't have any information about what IA64 does, but I think representing function pointers as 16 bytes would probably be a bad idea, since quite a bit of existing code assumes that function pointers are the same size as data pointers, and so I'd be somewhat surprised if they've really done that.) -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
participants (3)
-
Fergus Henderson -
Manuel M. T. Chakravarty -
qrczak＠knm.org.pl