apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: apr-iconv 1.0
Date Wed, 30 Mar 2005 00:32:44 GMT
At 05:12 PM 3/29/2005, Roy T.Fielding wrote:
>IMO, delete apr-iconv and let installers use the system-supplied

Respectfully, I don't think we can do so in apr-util 1.x.

The apr-util 2.0 release is the next major bump for deprecating 
interfaces, and we would have to alert users that it's as likely
as not that apr_xlate will return APR_ENOTIMPL more often than
it had previously done.

Nothing is stopping us from moving up to apr-util 2.0 tomorrow,
of course.

Now let me explain why we can't do this using Win32's internal
charset translation.  apr_xlate's api was too transparent around
iconv.  The Win32 API uses an all-or-nothing approach, returning
the number of bytes required to represent the translated text if
the results would not fit in the user supplied buffer.

The iconv implementation will perform a partial translation,
incrementing both the source and destination string pointers to
the end of the successfully translated text.

Because the source and destination code pages may match in bytes
per character, may be a multiple or fraction (e.g. ascii<>unicode)
or even multibyte representations, there is no way for the Win32
implementation to reinvoke w/the appropriate length of the source
text, except by backing up one byte at a time till we have a fit.

I understand there is a COM equivalent on Win32 that does perform
partial translations, but adding the COM overhead would be painful,
and surely less efficient than fitting iconv on win32.

My bottom-line proposal is to support iconv 2.0.3 on Win32, in the
framework of an iconv project.  I'm soliciting input from the
various platform maintainers of that long-neglected code.  Again
I don't see this change as realistic until apr-util 2.0.


View raw message