httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c
Date Fri, 05 Aug 2016 20:58:38 GMT
On Thu, Aug 4, 2016 at 2:33 PM, William A Rowe Jr <>

> On Thu, Aug 4, 2016 at 2:01 PM, Eric Covener <> wrote:
>> On Mon, Aug 1, 2016 at 3:22 PM, William A Rowe Jr <>
>> wrote:
>> > We have a few choices, but the bottom line is that we treat /r/n
>> > as 0x0a 0x15 on ebcdic, and perhaps fix our iconv mapping.
>> >
>> > Choice 1; map both 0x15 and 0x37 to ASCII 0x0d, which grows the
>> > number of ascii equivalents by one. Both would be treated at CTRL.
>> >
>> > Choice 2; invert our current mapping, ASCII NL to EBCDIC LF and
>> > visa-versa. That would leave 0x37 'unguarded' and allowed as opaque
>> > text chars.
>> >
>> > Choice 3; treat the entire C1 codeplane on EBCDIC as CTRLs, and
>> > ignore some 32 'opaque bytes' as unsupportable.
>> How about #2 with the below -- but using apr_xlate so it is the same as
>> runtime:
> Runtime is the issue, this module is set up for cross compilation,
> including
> between native ASCII architectures. The patch breaks all
> cross-compilation,
> AIUI, not exclusively EBCDIC target builds.
> I suspect that the generator is probably wrong for cross compilation on
> an ASCII origin/build box targeting an EBCDIC OS in the first place.
> It seems correcting the table is the correct way to go, by direct
> observation, and placing great faith that other than 0x15/0x37,
> the discrepancies between ASCII <> EBCDIC C0 mappings do
> not vary widely between EBCDIC mapping choices. Whether we
> fix cross compilation of an ASCII build to an EBCDIC target is
> a different question.
> An alternative is to directly speak iconv, /shrug.
> (I am not happy about changing the non-ebcdic build here, but it
>> should act just like a static support program)
> Static support programs don't have to be invoked on the build environment,
> today.
> But I'm still uneasy about leaving [correction] 0x25 / 37 unguarded.

So I dug deeper, found a few more references;

In EBCDIC -> ASCII I believe the safest course is to treat the dominant
compiler's representation of '\n' as ASCII NL 0x0A, no questions asked,
#error if not true.  I'd be entirely OK with either refusing the other or
as 0x85 the other value, between NL of 0x15 and LEN of 0x25. This would
be consistent with compiling almost any third party c sources as an httpd
loadable module.

View raw message