apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Issac Goldstand <mar...@beamartyr.net>
Subject Re: Really last call to roll Thurs 2100 GMT
Date Wed, 30 May 2007 19:54:18 GMT
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 :-/

Mime
View raw message