In 2.0.9, the following patch/code for getting what amounts to a binary string port worked.
commit 7f7a124d3470b0d566f796e88f4e2ad5aa043f16 Author: David Kastrup <d...@gnu.org> Date: Sun Sep 21 18:40:06 2014 +0200 Source_file::init_port: Keep GUILEv2 from redecoding string input diff --git a/lily/source-file.cc b/lily/source-file.cc index 1118b9d..75ed0d9 100644 --- a/lily/source-file.cc +++ b/lily/source-file.cc @@ -152,7 +152,11 @@ Source_file::init_port () // we do our own utf8 encoding and verification in the parser, so we // use the no-conversion equivalent of latin1 SCM str = scm_from_latin1_string (c_str ()); - str_port_ = scm_mkstrport (SCM_INUM0, str, SCM_OPN | SCM_RDNG, __FUNCTION__); + scm_dynwind_begin ((scm_t_dynwind_flags)0); + // Why doesn't scm_set_port_encoding_x work here? + scm_dynwind_fluid (ly_lily_module_constant ("%default-port-encoding"), SCM_BOOL_F); + str_port_ = scm_open_input_string (str); + scm_dynwind_end (); scm_set_port_filename_x (str_port_, ly_string2scm (name_)); } In 2.0.11, it doesn't. This is an incompatible API change within the "stable" 2.0 series. Since we are ping-ponging between GUILE and a native LilyPond interpreter and need to work with file offsets for keeping them in synch, it isn't an option to have scm_open_input_string convert to a different encoding. It also does not make sense from an efficiency point of view since strings are either encoded as latin-1 or UTF-32, so encoding string ports as UTF-8 without alternative means that it is _impossible_ to employ string ports efficiently and without conversion. -- David Kastrup