On Thu, Aug 4, 2016 at 2:01 PM, Eric Covener <cove...@gmail.com> wrote:
> On Mon, Aug 1, 2016 at 3:22 PM, William A Rowe Jr <wr...@rowe-clan.net> > 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: > > http://people.apache.org/~covener/patches/ebcdic-gen_test_char.diff > 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 0x37 unguarded.
