On Aug 5, 2016 4:37 PM, "Eric Covener" <cove...@gmail.com> wrote: > > On Fri, Aug 5, 2016 at 4:58 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Thu, Aug 4, 2016 at 2:33 PM, William A Rowe Jr <wr...@rowe-clan.net> > > wrote: > >> > >> 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:
> 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. According to our current implementation, it actually won't be hard to fix this at compile time, for cross compilation provided that both origin and target are 'some EBCDIC' arch. It should not be impossible to take that one step further and cross compile on an ASCII origin/build but that's a project for another month, if ever. First off, I am working to review all EBCDIC code page exceptions for the some 3 dozen installed here. They all follow the classic \x0D\x25 mapping. But I'll try to determine what the typical exceptions are within C0 and ASCII equiv. > 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. Easier is to do a compile time comparison of '\n' to 0x15 vs 0x25. But I need to know the mystery of 0x25's value through iconv on your architecture. Please research, if they simply trade places we are fine. If they both map to 0x0A in ASCII we simply treat them as equal in our comparison fn. And the resulting table will be correct irrespective of what iconv munging has been performed.
