bug#20109: Incompatible API change in 2.0 series for string port encoding

[David Kastrup <dak@gnu.org>]

In 2.0.9, the following patch/code for getting what amounts to a binary
string port worked.

commit 7f7a124d3470b0d566f796e88f4e2ad5aa043f16
Author: David Kastrup <dak@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