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