I would let freeHaskellFunPtr accept and ignore nullFunPtr, since I once had to write when (ptr /= nullFunPtr) $ freeHaskellFunPtr ptr and it can be seen as consistent with free.
This sort of behaviour is comon in C but I think this is mostly because C has such a weak type system. In the Win32 library, we took some care to distinguish between values which couldn't possibly be null (whether null pointers, null window handles, null font handles or whatever) using definitions like this newtype Window = Window Addr newtype Font = Font Int32 and values which could possibly be null: type MbWindow = Maybe Window type MbFont = Maybe Font This additional information made it easier to understand function types (because a bit more of the C documentation had migrated into the Haskell type), caught programming errors early, etc. This approach wouldn't be feasible in C because C's type system isn't expressive enough to express (and check!) these types. (Well, maybe you could use unions but it would be so clumsy as to be unusable.) Which is all just my long-winded way of saying I agree with Simon that we should not do this. Even if f.e.d. could return nullFunPtr, we should not do this because we can express it better using a Maybe. Alastair