"Simon Marlow" <simonmar@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@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.