On Fri, Aug 5, 2016 at 4:58 PM, William A Rowe Jr <[email protected]> wrote: > On Thu, Aug 4, 2016 at 2:33 PM, William A Rowe Jr <[email protected]> > wrote: >> >> On Thu, Aug 4, 2016 at 2:01 PM, Eric Covener <[email protected]> wrote: >>> >>> On Mon, Aug 1, 2016 at 3:22 PM, William A Rowe Jr <[email protected]> >>> 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 [correction] 0x25 / 37 unguarded. > > > So I dug deeper, found a few more references; > > https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014347663 > > https://en.wikipedia.org/wiki/Newline > > 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 > treating > 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.
I still think It has to match the apr_xlate result, which could be either flavor depending on whether iconv (0x15 <-> 0x0A and 0x25 <-> 0x85) or apr-iconv (opposite) is used on the EBCDIC platform I can test on. If apr-iconv is meant for systems w/o iconv, and there's only 1 supportable EBCDIC platform and its iconv has this quirk, we should use it instead of the real 037/1047 table because it will be applied to the protocol data this way. I haven't heard a peep about any other EBCDIC platforms in many years. We can #error in this EBCDIC block if __MVS__ is not defined. -- Eric Covener [email protected]
