Re: so... string work

    > From: Matthew Dempsky <[email protected]>

    > Hopefully last question before I can commit some basic string
    > functionality/frameworking -- what are the semantics regarding
    > `udstr_copy'ing and `udstr_ref'ing of `t_udstr's in the FFI?  I assume
    > scm_make_string should at least ref the string if not copy it, but I'm
    > not sure about the rest of the functions.

_extract_ functions copy -- data or the entire t_udstr depending on
which they return.

_lock_ should do nothing -- just lease the t_udstr to C code for a
while. The Scheme object is live between lock and unlock and holds a
reference.

The _make_ functions that accept raw string data (the portable FFI
functions) should copy that string data.

For naming consistency, if you need a string constructor function that
copies a t_udstr that it's handed, call that _make_.

If you need a string constructor that wraps an existing t_udstr,
I think it should be called "scm_take_*".   The thing is, after a
call like:

	scm_take_udstr (&answer, arena, udstr);

the value of `udstr' is no longer valid to the C code.   Before that
call, the C code must have had a reference count on `udstr'.   So
`scm_take_udstr' should just "take over" the reference count from C,
not increment the reference count.   It might even not be a terrible 
idea to make it:

	scm_take_udstr (&answer, arena, &udstr);

and, as a side effect, set `udstr' to 0 in `scm_take_udstr'.


(I think there should not be functions like `scm_take_string8' because
callers don't know how to allocate data for t_udstr's.  For example,
there might need to be extra stuff to the "left" of the start of the
string.)

-t