deRefStablePtr exception?

[Manuel M. T. Chakravarty]

"Simon Marlow" <simonmar at microsoft.com> wrote,

> > Aha!  I was reading the last sentence of the freeStablePtr description
> > as though it applied to freeStablePtr when in fact it means that
> > castStablePtrToPtr is guaranteed not to diverge.  Well that's a lot
> > easier to implement.

I have clarified the documentation here by explicitly
stating what call is meant to not diverge.

> > btw What am I to make of the parenthetical remark 
> > 
> >   (in particular it may be Ptr.nullPtr)
> > 
> > Should I read that as a recommendation to implementors that when
> > casting a stableptr which has already been freed then they should
> > return nullPtr?   If so, is this required or just hinted/recommended?
> 
> I'm not sure where this came from, perhaps Manuel can elucidate.  GHC
> doesn't do this; it just casts the stable pointer value to
> a Ptr.

This is at best a recommendation (as in programming errors
might be more easily caught this way), but it was actually
only meant to make absolutely clear that you can't do
anything with such a pointer.  If you think that the
parenthetical remark is confusing and should better be taken
out, I am happy to do so.

> > > Either 'ErrorCall "Foreign.StablePtr.deRefStablePtr: invalid stable
> > > pointer"', or a new exception.  I don't mind which.
> > 
> > I'll pick one and add my choice to the spec then.
> 
> The spec doesn't say anything about exceptions, and it isn't dependent
> on the implementation also supporting exceptions.  So all the spec
> should say is that deRefStablePtr on a stable pointer which was not
> generated by newStablePtr, or has already been freed, has undefined
> behaviour.

That's what I think, too.  My reading always was that, as
StablePtr is effectively an abstract type, you can't get a
stable pointer other than from the routines in the StablePtr
module anyway.  Anyway, I have added to the description of
`castPtrToStablePtr' the following:

  Moreover, \code{castPtrToStablePtr} may only be applied to
  pointers that have been produced by \code{castStablePtrToPtr}.

And I have noted in the description of `deRefStablePtr' that

  If the argument to \code{deRefStablePtr} has already been
  freed using \code{freeStablePtr}, the behaviour of
  \code{deRefStablePtr} is undefined.

Alastair Reid <reid at cs.utah.edu> wrote,

> Hmmm.  I vaguely remember (but can't locate at the moment), the spec
> guaranteeing that valid HsStablePtrs are nonNull.  Maybe it is a
> reference to that?
> 
> [Am I right that they must be non-Null?]

I don't think that there is any such guarantee.

> Simon:
> > The spec doesn't say anything about exceptions, and it isn't
> > dependent on the implementation also supporting exceptions.  So all
> > the spec should say is that deRefStablePtr on a stable pointer which
> > was not generated by newStablePtr, or has already been freed, has
> > undefined behaviour.
> 
> Ok then, IOErrors are part of H98 and even get mentioned in the ffi
> spec.  Can we at least specify that you get an IOError if you 
> 
>   deRefStablePtr (castPtrToStablePtr (Ptr.nullPtr))
> 
> (Of course, implementations might raise the same error for other
> invalid stable pointers - but it's hard to make firm guarantees.)

IMHO the whole exception story in Haskell is very far from
being consistent or in any other way satisfying.  H98 uses
exceptions only for really I/O related failures.  Of course,
it would be much nicer to follow the ML example and use them
consistently for all error conditions.  GHC goes in that
direction, which I like very much, but I don't think we
should put anything like this into the FFI spec, which
relies on H98 only.  

Consequently, I don't see much point of "abusing" H98 IO
exceptions to handle non-I/O-related error conditions in
functions that happen to be living in the IO monad (because
they are having side effects).

Also note that by the clarification of `castPtrToStablePtr'
the subexpression

  castPtrToStablePtr (Ptr.nullPtr)

in your example is already undefined.

Cheers,
Manuel

PS: It is really good to have somebody implementing the FFI
    in another Haskell system and shaking out all these
    ambiguities in the spec!

PSS: I'll also be responding to the other FFI discussion,
     but I just was quite bogged down with other stuff -
     sorry.