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:
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
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.
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.
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
bufWrite are unnecessary, though.