William A. Rowe, Jr. wrote: > Issac Goldstand wrote: > >> Any chance someone can review the patch at >> http://issues.apache.org/bugzilla/show_bug.cgi?id=42526 for considered >> inclusion in the next set of tarballs? >> > > If it treats endianness correctly by cpu, I'm all for it. > > However, if http://issues.apache.org/bugzilla/attachment.cgi?id=20277 > simply maps both to the default endianness, this patch is silly ;-) > > Without my spending 30 minutes in there, can you describe how -BE and > -LE mappings produce the CORRECT unicode word encodings independent of > the platform's default? > > Bill > I'm no iconv guru - I know that on systems with gnu iconv, I can specifically request -BE and -LE. I actually naively assumed that apr-iconv can support both ways; for example with the Apache HTTP server, I can't see the usefulness of a BE server sending to an LE client (or vice versa) without a BOM. And even if we'd make sure to send one, the same could be applied for sending UTF-16 in the request, where there's no way to get the BOM.
Having looked a bit at the sources, I see that that's not the case. It's tired and my head hurts, but there seems to be a way to specify endianness by setting ces->data to 1 or 2. Otherwise with writes, it assumes the endianness of the system and prepends a BOM, and with reads it assumes HSB order. Unfortunately, this isn't something I can really attack now, so I guess it'll have to wait a bit longer :-/
