[plt-scheme] bytes vs u8vector

On Sat, Jan 28, 2006 at 11:47:17AM -0500, Eli Barzilay wrote:
> Byte strings are neither more nor less primitive than u8vectors.  They
> are different facilities.

I think we may be talking about slightly different things. When I say
"u8vector", the intension is "the data type that srfis 4 and 66 define".
It is only an accidental fact that the implementation of srfi-4 in
mzscheme is based on the FFI.

To you, on the other hand, I surmise that "u8vector" means primarily the
data type used in the FFI to communicate binary data to and from C code
and it's only an accidental fact that it's also used to implement an
SRFI.

So, in a sense you are wrong: the functionality that the srfi-u8vector
provides is exactly the functionality that byte strings provide.

And in a sense you are right: the u8vector type in the FFI serves a
different purpose from the byte strings.

> The problem is not when a byte string is allocated, it's when a
> foreign function returns a "u8vector" -- it cannot be made into a byte
> string, so there should be two types at the low-level implementation.

Do you mean that the FFI guarantees that a byte string's contents can be
accessed directly and it will be null-terminated? And there's already
existing code that relies on this? That would indeed be a problem.

Hm, I've never really looked at the FFI before... do I gather correctly
that it's possible to create byte strings whose data actually resides at
some pointer that's been returned from the C world? I don't see how
memory management can work with such an arrangement.


Lauri