FFI Bug - Finalizer always called with NULL pointer?

[Brian Hulley]

> [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... :-)