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

Re: Octet vs Char (Re: strings draft)

This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.




On Sun, 25 Jan 2004, Shiro Kawai wrote:

>I think using strings for binary I/O should be explicitly
>discouraged, even though an octet sequence can be represented by
>using such special characters.  It can be very inefficient
>on some implementations, and it may cause problems on ports
>that deals with character encodings.

Hear, Hear.  The standard goes out of its way to *not* assume
a particular character encoding and repertoire; it follows that
code relying on a particular character encoding in order to do
binary I/O is nonportable.

We should never need to know what the binary encoding of some
character 'C' is in order to write a .jpg file to disk, but as
matters stand we do.  It makes no damn sense that a program that
attempts to write a graphic format or a sound file has to rely
on ASCII encodings for characters and will fail if run on a
machine whose character encoding is different -- EBCDIC, or
utf-8, or utf-16, etc.  This program is not even manipulating
text; why should character encodings be capable of causing it to
fail?

				Bear