How about making SCHEME_EXTRACT_STRING returns const char*?

(Well, the current spec allows the caller to change the buffer
in-place, and to call SCHEME_ENTER_STRING with the buffer.
That doesn't look like a good practice to me, though.  Also it
forces the shared string implementation to copy string body
every time SCHEME_EXTRACT_STRING is called.)

If there's a reason not to make it const char*, then I second
to make it explicit that it's undefined whether writing to the
result may or may not affect the original Scheme string.

--shiro

>From: bear <xxxxxx@sonic.net>
Subject: Strings, one last detail.
Date: Fri, 30 Jan 2004 13:12:09 -0800 (PST)

>
> Okay, I'm still looking at this "portable" FFI and there's one crucial
> thing missing to make it portable, in terms of strings.
>
> I can treat SCHEME_EXTRACT_STRING as a request to make a copy of a
> string in a format acceptable to C code in some buffer, register it as
> "floating garbage" with the GC, return a pointer to that buffer, and
> lock the garbage collector until the scheme runtime is reentered.  If
> the C code just wants to _read_ what's there, that's necessary and
> sufficient.  But a developer looking at the specification of
> SCHEME_EXTRACT_STRING ("a pointer to the storage occupied by the
> characters of the string") may expect to be able to _write_ the
> contents of the buffer and have the changes written show up in the
> string on the scheme side, and code relying on that will be a problem.
>
> I see another routine, SCHEME_ENTER_STRING, that is clearly the correct
> way to assign a changed string value to a scheme string variable from C
> code.
>
> What's missing is an explicit declaration that it is unspecified
> whether or not values written into the buffer pointed at by the result
> of SCHEME_EXTRACT_STRING mutate the scheme string that was originally
> referred to,
>
> You come close to saying this when you mention that the pointer may
> only be valid until the next GC, but reading it out of that statement
> takes a basic understanding of copying GC's and more thought about
> their interaction with the runtime than I think a lot of people will
> expend.
>
> 				Bear
>