bug-guile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andy Wingo
Subject: bug#20109: Incompatible API change in 2.0 series for string port encoding
Date: Thu, 23 Jun 2016 18:23:05 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

On Fri 17 Apr 2015 07:17, Mark H Weaver <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> In 2.0.9, the following patch/code for getting what amounts to a binary
>> string port worked.
>>
>> commit 7f7a124d3470b0d566f796e88f4e2ad5aa043f16
>> Author: David Kastrup <address@hidden>
>> 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.

I believe Mark is right -- the change to string ports is only on
`master'.  Given that, I think the bug can be closed.  David does this
match your perception?

Andy





reply via email to

[Prev in Thread] Current Thread [Next in Thread]