Hi all,
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. My base64 encoding and decoding functions sort
of make this assumption, by ripping out the low 8 bits of chars before
encoding this binary representation (3x8bit chars become 4x6bit base64
chars).
So far everything works fine, but is this approach going to break in the
near future? What I would like to see are socket functions that do not
introduce this extra level of binary indirection, perhaps using a ByteArray,
or Word8 (as I see has previously been discussed -
http://www.haskell.org/pipermail/libraries/2001-August/000482.html) How
realistic is this?
Warrick.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
