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 at haskell.org[mailto:glasgow-haskell-users-
|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
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 at haskell.org|http://www.haskell.org/mailman/listinfo/glasgow-haskell-users