Hunt down uses of `castPtr`
This bug is a fork from #9163 (closed):
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.
Trac metadata
Trac field | Value |
---|---|
Version | 7.8.2 |
Type | Task |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | libraries/base |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | ekmett, hvr |
Operating system | |
Architecture |