String type in Socket I/O
Mon, 8 Apr 2002 12:08:44 +0100

Having written a Haskell LDAP interface, this is something that worried me
but I never got to the bottom of. I've cross-posted this to haskell
(hopefully the right place). There was some discussion of replacing Char by
a type for raw bytes / octets but I'm not sure what happened to it.


"Warrick Gray" <> on 07/04/2002 13:31:41

Sent by:

To:   libraries
Subject:  String type in Socket I/O

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
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
SocketPrim.sendTo function?  My current guess is that the low 8 bits of
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

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
or Word8 (as I see has previously been discussed -  How
realistic is this?


Get your FREE download of MSN Explorer at

Libraries mailing list


      Save time by using an eTicket and our Self-Service Check-in Kiosks.
      For more information go to