> I am writing an HTTP client-side library, using the
> SocketPrim library.
> During the implementation of Base64 encode/decode I began to
> have some
> doubts over the use of the Char type for socket I/O.
>
> As far as I can tell, "sendTo" and "recvFrom" are simply
> handles on the
> underlying OS calls. My winsock2.h file tells me the data
> passed into and
> received from these functions are C style chars, 8 bits each.
> In unix these
> functions (sys/sockets.h) appear to use a C void pointer.
> Finally I notice
> that the Haskell98 report defines Haskell Char as a Unicode
> char (which I
> figure isn't guaranteed 8 bits).
>
> So I am curious, what happens when I send these unicode
> Haskell chars to the
> SocketPrim.sendTo function? My current guess is that the low
> 8 bits of each
> Char become a C style char.
That's what happens in GHC, but as you correctly point out this is
wrong. The real problem is twofold: GHC doesn't have proper support for
Unicode encoding/decoding at the I/O interface, and we don't have an
"approved" way to write other kinds of data into a file.
In GHC we currently have this interface (not in a released version yet)
in the module Data.Array.IO:
hGetArray :: Handle -> IOUArray Int Word8 -> Int -> IO Int
hPutArray :: Handle -> IOUArray Int Word8 -> Int -> IO ()
and there's also a Binary I/O library I've been working on that can be
used for reading/writing Word8s and other low-level kinds of data in a
predictable way (I guess we should discuss what the interface to
Data.Binary should look like at some point).
I'd also be happy to add
hPutWord8 :: Handle -> Word8 -> IO ()
hGetWord8 :: Handle -> IO Word8
to System.IO if people think this is the right thing to do.
Cheers,
Simon
