httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Covener <cove...@gmail.com>
Subject Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c
Date Mon, 01 Aug 2016 15:55:41 GMT
On Mon, Aug 1, 2016 at 11:28 AM, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
> On Sun, Jul 31, 2016 at 11:51 AM, Eric Covener <covener@gmail.com> wrote:
>>
>> On Sun, Jul 31, 2016 at 12:19 PM, William A Rowe Jr <wrowe@rowe-clan.net>
>> wrote:
>> > Not a conclusion, but this is obviously a bigger headache...
>> >
>> >
>> > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ioea600/smbadap021003899.htm
>>
>> I don't think this is an issue for httpd. There are a number of
>> auto-conversion things at different layers, but the low level ones
>> that would affect our calls are opt-in.  That SMB server link for
>> example is more the equivalent of saying what mod_charset_lite does by
>> default rather than what a filesystem or C lib might do by default.
>
>
> The most important question is what is printf("%02x %02x\n", (int)'\r',
> (int)'\n');
> If '\n' is actualiy 0x15 we may as well flip LF and NL for the purposes of
> our
> table.

Output is what you anticipated -- 0d 15

native iconv on the host does xlate back and forth as 0x15<->0x0a

I notice ebcdic-us.c in apr-iconv has this mapping instead of 0x85

Note: AFAIK IBM has always used native iconv on the mainframe for
httpd, so synching up with apr-iconv tables is probably not paramount.

Mime
View raw message