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