Hi, remember me? ;-)
I’m writing because I was pondering EBCDIC for an upcoming change. Daniel Richard G. dixit: >I don't think there would be any instance where the code needs to know >"I am building for EBCDIC 1047" vs. "for EBCDIC 037" or whatnot. The >transcoding of char/string literals should be all that's needed. Unfortunately, this is not true, and this ties in with this part of an earlier mail in this thread: >> I was thinking of this: >> >> $ echo '+' | tr '(-*' '*-,' >> + >> >> This should give a ‘)’ in EBCDIC, right? > >Hate to disappoint... > > $ echo '+' | tr '(-*' '*-,' > + In the meantime I learnt why: POSIX ranges are always in ASCII order, so [A-Z] won’t match any nōn-letters even on EBCDIC systems. For this to work however I require a table mapping all 256 EBCDIC octets in the compile-time (= run-time) codepage onto their ASCII equivalents, or -1 if there is no match (in which case they just sort higher than any char that actually _is_ in ASCII, and probably by ordinal value). I guess this means we’ll have to include a translation table at compile time, and possibly multiple in the code (if we want there to be a choice of codepage). I’m unsure if you actually want to support at least both 1047 and 037 in the future or if restricting yourself to 1047 is good enough especially considering that OpenSSL application note you posted and the compiler defaulting to that. I’ll just keep this in mind but implement that feature, out of necessity for it to be there rather soon, ASCII-only for now (it’s one that won’t work in utf8-mode either anyway). bye, //mirabilos -- 18:47⎜<mirabilos:#!/bin/mksh> well channels… you see, I see everything in the same window anyway 18:48⎜<xpt:#!/bin/mksh> i know, you have some kind of telnet with automatic pong 18:48⎜<mirabilos:#!/bin/mksh> haha, yes :D 18:49⎜<mirabilos:#!/bin/mksh> though that's more tinyirc – sirc is more comfy
