Re: Adding new information to scm_t_port (was Re: always O_BINARY?)

[ludo@gnu.org (Ludovic Courtès)]

Andy Wingo <wingo@pobox.com> skribis:

> On Thu 28 Feb 2013 12:04, ludo@gnu.org (Ludovic Courtès) writes:
>
>> Andy Wingo <wingo@pobox.com> skribis:
>>
>>> On Thu 28 Feb 2013 04:24, Mark H Weaver <mhw@netris.org> writes:
>>>
>>>> Instead of having 'input_cd' and 'output_cd' point directly to the
>>>> platform's iconv_t structures, let's have them point to our own internal
>>>> structure(s) that hold the needed transcoder state.  This could include
>>>> things like the state for internally-implement encoding(s) (e.g. UTF-8
>>>> BOM handling), EOL style, and iconv_t pointer(s) if appropriate.
>>>
>>> Great idea.
>>>
>>> I would call it a generic "port-private" data structure; it is not
>>> limited to transcoder state.
>>>
>>>   struct scm_t_port_private;
>>>   #define SCM_I_PORT_PRIVATE ((struct scm_t_port_private*)((ptob)->input_cd))
>>
>> Sounds good to me, perhaps with ‘input_cd’ changed to ‘internal’ or
>> similar.
>
> That would be an API break; probably best to keep it with the same name,
> no?  Though I guess it doesn't matter in this particular case...

I’d say it doesn’t matter in this case because I can hardly imagine
someone doing something useful with ‘input_cd’ outside of Guile.

Ludo’.