After replacing Boehm with the new GC, I just removed the the final non-standard dependency in chibi-scheme, C string streams, which are used to implement Scheme's string ports. Now if your libc doesn't have C streams, Chibi will provide its own simplistic alternative. The allows Chibi to build and run on Plan 9 (though there are still some bugs to be worked out), and should port fairly easily to Windows.

Although string ports are only a semi-standard extension to Scheme, they are fairly widely implemented, and are needed for some of the string conversion routines in Chibi. Also, they're incredibly useful. Whenever you have a non-trivial utility for processing textual data, such as a parser, it can be useful to apply the utility to either in-memory strings or to file streams. Providing both interfaces doubles the API,^[1] and causes corresponding code duplication.^[2]

To alleviate this problem, there are various extensions to libc allowing you to treat a string as a stream. You can then write the API only worrying about streams, and let the user convert to and from strings as necessary.^[3] The POSIX [http://www.opengroup.org/onlinepubs/9699919799/functions/fmemopen.html fmemopen(3)] extension lets you open a string as an input port, while [http://www.opengroup.org/onlinepubs/9699919799/functions/open_memstream.html open_memstream(3)] can be used to accumulate output to a port into a string. In addition to API simplification, these functions help reduce errors in constructing strings by preventing buffer overflows. BSD systems provide the [http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/funopen.3.html funopen(3)] function, which accepts callback functions for reading, writing, seeking and closing in a virtual stream.^[4] Rather than a string, these callbacks are passed an opaque void* cookie, allowing you to base your streams on whatever you want.

While it's trivial to implement fmemopen(3) with funopen(3), the only truly portable implementation is to write to and read from temporary files, which is silly. So I was held up in porting to Plan 9 and Windows, and I certainly didn't want to duplicate the sexp reader for both strings and streams. Now, Plan 9 is a very minimal OS, and traditionally it focuses on separate programs rather than libraries, and simple line-oriented formats that are easy to pass through a pipeline, so it has little use for parsers, which explains why Plan 9 doesn't have the equivalent functionality. But why Windows should have no equivalent, despite the usefulness and immunity to buffer overflows at first surprised me, until I remembered Windows is fundamentally a C++ OS. The C++ equivalent is [http://www.cplusplus.com/reference/iostream/stringstream/ stringstreams], or more generally to simply provide your own class which overloads the << and >> iostream operators. funopen(3) with its callback functions and opaque cookie is just the C way of rolling your own object system.

In the end, I fell back on the old adage that you can solve any problem with an extra level of indirection. So when neither fmemopen(3) nor funopen(3) are available, chibi will implement string ports by maintaining its own buffer in the port structure, which otherwise contains the C stream. It works, but it would be nice if more systems provided string streams by default.