On Apr 7, 2005, at 10:54 AM, William A. Rowe, Jr. wrote:
At 03:06 PM 4/6/2005, Curt Arnold wrote: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:
If the final call is made as suggested, apr_iconv will case a null pointer exception. GNU iconv does not.
I'll look. My concern is that this suggested doc change is part of a gnu libiconv-ism, which would break on FreeBSD. But I need to look.
I wasn't suggesting a doc change, the doc is right and doing the final call to apr_xlate(&conv, NULL, NULL) is the proper thing to do though it is only essential for some fairly obscure encodings. However, if you do the right thing and apr_xlate is using apr_iconv, it will fault.
2. apr_iconv does not have a WCHAR_T encoding.
Isn't wchar_t the preference, from ANSI/C99 headers?
The encoding and width of the wchar_t type is platform-dependent. GNU iconv has an encoding named "WCHAR_T" that can be used to convert, for example, from a wchar_t* to some other encoding. Without an "WCHAR_T" encoding, my code needs to know that wchar_t* on Win32 is UTF-16LE, UCS-4 on some other platform, etc and use the appropriate encoding name.
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".
If you are really interested in tracking these down, I can write the test cases. However just the number of issues I was immediately running into was enough to make me rethink my plan on using apr-xlate for encoding services on all platforms.
