Would you like to add to the GHC FAQ, or even start a "Hints about using the FFI" page? http://haskell.org/haskellwiki/GHC:Documentation (The section at the bottom called "collaborative documentation" is the place.) Hard-won experience like this should be captured. GHC's documentation is a Wiki specifically so that you can record it. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Brian Hulley | Sent: 08 April 2006 10:35 | To: Brian Hulley; glasgow-haskell-users@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 thought | '&' 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, without | the &, was declaring duma_releaseFont to be a function taking no args and | returning a FunPtr, whereas with the &, I am declaring duma_releaseFont to | be the FunPtr itself. The '&' is needed because otherwise there would be no | way to distinguish the wrapping of a C function in a FunPtr and a C function | returning a FunPtr. | | So in a way it is "obvious" but only when it is realised that '&' actually | means something in Haskell FFI even though it is irrelevant (when taking | about functions) in C. | | Therefore there is no bug anywhere. It is just that FFI has a high learning | curve since it rests on extremely subtle but vital distinctions foreign to a | C programmer... :-) | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users