Hello Thorsten,
On Thu, 2017 Apr 20 19:14+0000, Thorsten Glaser wrote:
> Hi,
>
> remember me? ;-)
I sure do!
> 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.
Interesting! So POSIX assumes ASCII, to a certain extent.
> 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.
It wouldn't work to do the EBCDIC->ASCII conversion all at runtime? z/OS
does provide functions for this, and these will adjust to whatever the
current EBCDIC codepage is:
etoa():
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxbd00/r0ceta.htm
etoa_l():
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxbd00/r0etal.htm
Even if you really do need a table, you could populate it on startup
using these.
> 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).
I guess multi-byte is trickier... EBCDIC does have the
limitation/advantage of still being one byte per character. (UTF-EBCDIC
is definitely not a thing in IBM mainframe land)
Anyway, if you need any z/OS testing, feel free to drop me a line ;)
--Daniel
--
Daniel Richard G. || [email protected]
My ASCII-art .sig got a bad case of Times New Roman.
