SimonM:

...

That's a good point, I don't think it has any error checking at all. Of course the only way to get an invalid stable pointer is by calling freeStablePointer on a valid one, or by using the FFI.

From an imported C function:

return (HsStablePtr)0

From Haskell code:

castPtrToStablePtr Ptr.nullPtr

My reading of the description of freeStablePtr is that it is perfectly legal to pass around a (void*)0 as an HsStablePtr and to hand that to freeStablePtr and castStablePtrToPtr and expect something meaningful to happen.

The description of freeStablePtr says that the behaviour is undefined when passed an already-freed stable pointer, so I assume it is also undefined if passed a stable pointer that was never obtained from newStablePtr in the first place (perhaps the spec should say this explicitly). But you seem to be saying that freeStablePtr (castPtrToStablePtr Ptr.nullPtr) is meaningful... which part of the spec implies that?

(My personal leanings with anything resembling a C pointer have always been to use some variant of

Maybe Addr Maybe (Ptr a) Maybe (FunPtr a) Maybe (StablePtr a)

if the pointer can possibly be null. It turns out that many functions assume their argument cannot be null or guarantee that their result is not null and this both catches errors and reminds the programmer to think about the null case.)

Couldn't agree more.

...

Nevertheless, deRefStablePtr should raise an exception when it finds an invalid stable pointer.

Which brings me back to my question: _which_ exception should it raise?

Either 'ErrorCall "Foreign.StablePtr.deRefStablePtr: invalid stable pointer"', or a new exception. I don't mind which. Cheers, Simon