Calls to list->string fail when character 0 is included in the list
passed as its first argument, as in:

  (list->string (list (integer->char 0) #\a))

The  code above  generates the  following runtime  error for  the
resulting program:

Guile does run that code without problems.

Why make it  impossible for strings to hold character  0 on them?
It  makes it  problematic  to create  code  to read/write  binary
files.

(Please preserve the -forwarded address in any replies.)

Alejandro Forero Cuervo <bachue@bachue.com> writes:

I'll forward this upstream, but standards-wise, I don't think R5RS
Scheme strings are designed or defined to support binary data.  Guile
just happens to.

FWIW, among other things, a standard for strings as binary data
structures (i.e. pretending that Scheme strings have the same
conflation that C does) would have to address issues of character
width (8-bytes, 16-bytes, etc.).  Might be a good topic for a SRFI
discussion (srfi.schemers.org).

The reason for this is that Stalin uses the same representation for strings as
C. Strings are null-terminated and do not have any other length field. This
has advantages and disadvantages. The advantage is that FFI calls to and
returns from C have zero overhead when passing and returning strings. The
disadvantages are:

 1. You can't store nulls in strings.
 2. string-length is O(n) instead of O(1)
 3. bounds checking during string-set! and string-ref are O(n) instead of O(1)

RnRS does not require strings to be able to store nulls. It only defines a
subset of the ascii characters and doesn't even define the bijection between
characters and integers.

So this is not a bug. It is a design tradeoff.

In Stalin, you can use vectors. If you make sure that vectors store only
characters then type inference will get you a vector of bytes headed by a
length field. You can store nulls in this.

    Jeff (http://www.ece.purdue.edu/~qobi)