This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
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