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