deRefStablePtr exception?

Simon Marlow simonmar at microsoft.com
Thu Jun 13 07:23:24 EDT 2002


> 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



More information about the FFI mailing list