[GHC] #9164: Hunt down uses of `castPtr`

[GHC]

#9164: Hunt down uses of `castPtr`
------------------------------------+-------------------------------------
       Reporter:  nomeata           |             Owner:
           Type:  task              |            Status:  new
       Priority:  normal            |         Milestone:
      Component:  libraries/base    |           Version:  7.8.2
       Keywords:                    |  Operating System:  Unknown/Multiple
   Architecture:  Unknown/Multiple  |   Type of failure:  None/Unknown
     Difficulty:  Unknown           |         Test Case:
     Blocked By:                    |          Blocking:
Related Tickets:                    |
------------------------------------+-------------------------------------
 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.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9164>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler