FFI Bug - Finalizer always called with NULL pointer?
simonpj at microsoft.com
Mon Apr 10 03:30:56 EDT 2006
Would you like to add to the GHC FAQ, or even start a "Hints about using
the FFI" page?
(The section at the bottom called "collaborative documentation" is the
Hard-won experience like this should be captured. GHC's documentation
is a Wiki specifically so that you can record it.
| -----Original Message-----
| From: glasgow-haskell-users-bounces at haskell.org
| bounces at haskell.org] On Behalf Of Brian Hulley
| Sent: 08 April 2006 10:35
| To: Brian Hulley; glasgow-haskell-users at haskell.org
| Subject: Re: FFI Bug - Finalizer always called with NULL pointer?
| > [Helpful off-list suggestion to look at FFI spec for & more closely]
| Thanks. I'd read it several times before but hadn't understood the
| difference between a function and the address of a function and so
| '&' was optional, as it is in C for functions:
| void foo();
| typedef void (*Fun)();
| Fun a = &foo;
| Fun b = foo; // same as above (in VC7)
| However I see now that in the Haskell FFI my original declaration,
| the &, was declaring duma_releaseFont to be a function taking no args
| returning a FunPtr, whereas with the &, I am declaring
| be the FunPtr itself. The '&' is needed because otherwise there would
| way to distinguish the wrapping of a C function in a FunPtr and a C
| returning a FunPtr.
| So in a way it is "obvious" but only when it is realised that '&'
| means something in Haskell FFI even though it is irrelevant (when
| about functions) in C.
| Therefore there is no bug anywhere. It is just that FFI has a high
| curve since it rests on extremely subtle but vital distinctions
foreign to a
| C programmer... :-)
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users at haskell.org
More information about the Glasgow-haskell-users