Hunt down uses of `castPtr`
|Reported by:||nomeata||Owned by:|
|Type of failure:||None/Unknown||Test Case:|
|Related Tickets:||Differential Rev(s):|
This bug is a fork from #9163:
nomeata: Slightly off topic, but maybe GHC.IO.Handle.Text can be written so that castPtr is not needed. It seems it always works with Ptr Word8, but exposes an API that uses Ptr a as a generic pointer. The type a is never needed inside GHC.IO.Handle.Text...
I tried it, and hPutBuf & Co are called with Ptr Word8 (sometimes called LitString) in all cases but BufWrite.bPutCStringLen, where we have a Ptr CChar, where CChar is a newtype. So by using coerce there (and unsafeCoerce during bootstrapping), we get the best of boths worlds: The more restrictive role and the free behaviour.
SPJ: Well regardless of the decision about the role of Ptr, what you describe sounds like an improvement anyway, getting rid of (always suspicious) castPtr calls. If you grep in the base library you'll find quite a few others. Can you eliminate them in the same way?
I think this would be a nice improvement, if you cared to push it through.
simonmar: So I've been assuming that castPtr was free all this time, and it turns out it isn't! Please make it free.
We can't change the type of hPutBuf and friends without potentially breaking code. There's no better choice than Ptr a here, because we don't know the type of the underlying data. Making it Ptr Word8 would just force the caller to use castPtr sometimes without any benefit. e.g. Ptr CChar is also a sensible choice, but it could in reality be anything.
It does look like the two castPtrs in bufWrite are unnecessary, though.