[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pika-dev] so... string work
From: |
Tom Lord |
Subject: |
Re: [Pika-dev] so... string work |
Date: |
Sun, 25 Jan 2004 08:37:33 -0800 (PST) |
> From: Matthew Dempsky <address@hidden>
> 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
- Re: [Pika-dev] so... string work, (continued)
- Re: [Pika-dev] so... string work, Matthew Dempsky, 2004/01/24
- Re: [Pika-dev] so... string work, Tom Lord, 2004/01/24
- Re: [Pika-dev] so... string work, Tom Lord, 2004/01/24
- Re: [Pika-dev] so... string work, Matthew Dempsky, 2004/01/24
- Re: [Pika-dev] so... string work, Tom Lord, 2004/01/24
- Re: [Pika-dev] so... string work, Matthew Dempsky, 2004/01/24
- Re: [Pika-dev] so... string work, Tom Lord, 2004/01/24
- Re: [Pika-dev] so... string work, Matthew Dempsky, 2004/01/25
- Re: [Pika-dev] so... string work, Tom Lord, 2004/01/25
- Re: [Pika-dev] so... string work, Matthew Dempsky, 2004/01/25
- Re: [Pika-dev] so... string work,
Tom Lord <=