[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
