Re: so... string work

    > From: Matthew Dempsky <[email protected]>

    > Tom Lord <lord-1tv/[email protected]> writes:

    > > So, to sum up the implications for Pika of that long thing:

    > > Strings will be "vtable objects" containing a pointer to a `t_udstr'
    > > (see src/hackerlab/strigns).

    > I meant to ask this earlier, but when you say the vtable object should
    > contain "a pointer to a t_udstr", is that intentional or
    > accidental?

Accidental.

    > Since t_udstr itself is a pointer value and I don't see any hackerlab
    > routines yet that require a t_udstr *, am I missing something?

    > A routine like:

    > 	t_udstr scm_string_value (t_scm_arena arena, t_scm_word * value);

    > should have a GC-independant lifetime like the scm_big(num|rat)_value
    > functions.

That's a trickier issue.  

It would be good to have 

   t_scm_error scm_extract_string (t_udstr * answer, [....])

but not an `scm_string_value' that gives you the _same_ t_udstr used
by the Scheme string (except in the innards).

The issue is t_udstr is not intended to be a thread-safe or async-safe
function.   A t_udstr owned by a Scheme object may change size or
encoding or (data) address at essentially any time.

With one exception:  This is what scm_lock_string_data and
scm_lock_string_data2 are for.   Between them and the corresponding
scm_release_* call, the t_udstr(s) is (are) promised to be stable.

-t