David Kastrup <d...@gnu.org> writes:
> 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.
Are you sure that you weren't using Guile from our 'master' branch? I'm
not aware of any change made on our stable-2.0 branch that would break
the above approach.
We _did_ make an incompatible change that would break this approach on
our master branch, which will become Guile 2.2. On that branch, string
ports always use UTF-8 to encode the initial string, and UTF-8 is always
used as the initial port encoding. However, stable-2.0 still uses
%default-port-encoding.
Mark
