I have ran into several issues when using apr_xlate delegating to (a hacked) apr-iconv which I did not encounter when delegating to iconv. I don't believe the issues are related to my hacking of the load process, but that is always a possibility. At this point, my plans are to use Win32 API calls to support a small set of encodings on Windows and apr_xlate on other platforms.
The issues that I ran into:
1. apr_iconv dereferences inbytes_left without checking for NULL
From the doc comments from apr_xlate_conv_buffer:
* To correctly terminate the output buffer for some multi-byte * character set encodings, a final call must be made to this function * after the complete input string has been converted, passing * the inbuf and inbytes_left parameters as NULL. (Note that this * mode only works from version 1.1.0 onwards)
If the final call is made as suggested, apr_iconv will case a null pointer exception. GNU iconv does not.
2. apr_iconv does not have a WCHAR_T encoding.
3. apr_xlate_open(&convset, APR_LOCALE_CHARSET, ...) fails for common code pages (like 1252) on Windows
This could be an artifact of my hacking. When this is attempted on my machine, the code determines the current code page (in my case 1252, Western European) and creates a corresponding encoding name like Cp1252. However, the corresponding encoding module is called "windows-1252" not "Cp1252".
The last two may be artifacts of my hacking. I didn't see any code that appeared to alias Cp1252 or WCHAR_T to an available encoding, but maybe I missed something. However, it was enough to shake any confidence I had in the approach I was using.
