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.
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 <bear@xxxxxxxxx> 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 >