[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Trouble w/sockets

From: Chris Vine
Subject: Re: Trouble w/sockets
Date: Sun, 3 Mar 2013 10:36:31 +0000

On Sat, 2 Mar 2013 20:48:45 -0800 (PST)
Mike Gran <address@hidden> wrote:
> The problem with `write-char' in Guile 2.0 is that it does all the
> conversion to the current locale.  So, once you start hitting the
> bytes greater than 127 in your string, `write-char' tries to convert
> each byte to something in your encoding.
> If your encoding is "C" or anything that strictly uses ASCII as its
> character encoding, it'll throw an error when its trying to print any
> byte above 127.  If your encoding is UTF-8, those high bytes will
> become two byte strings.
> Ideally you'd be able to use bytevectors or binary ports or some such.
> But you can also fake it by setting the port encoding to ISO-8859-1.
> In that encoding the characters 0 to 255 map one-to-one with the bytes
> from 0 to 255.
> (set-port-encoding! sock "ISO-8859-1")

Whilst this seems to be a side issue with respect to the OP's
problem, with R6RS you can use the 'put-u8' procedure to write
individual octets to a binary port (and 'get-u8' to read them) [1].

I know guile-2.0 doesn't distinguish between text and binary ports, but
presumably these procedures work without causing the port to undertake
charset conversion otherwise they are useless.  For example, I notice
that a port created with the 'pipe' procedure reports itself as both a
binary port and a textual port if 'setlocale' has not been called, but
as a textual port only if (setlocale LC_ALL "") has been called.
However, this does not seem to mean anything: in either case put-u8 and
get-u8 appear to work correctly.


[1] A someone unfortunate choice of name.  Here u8 presumably means
unsigned octet, not UTF-8 as in C11 and C++11.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]