Hi Bruno, On Sun, 2020 Jan 19 19:13-05:00, Bruno Haible wrote: > > OK, then we'll need > a) for the short-term: in lib/iconv_open.c, apply an EBCDIC -> ASCII > conversion to the 'from' and the 'to' strings. Can you implement that? > And also a rule that removes the anti-EBCDIC guard from the gperf > generated output (in modules/iconv_open). Please see the attached patch to iconv_open.c. I'll leave the makefile rule to you, as that is less straightforward for me. The patch, plus a disabled #error in iconv_open-zos.h, gets test-iconv to build and pass. However, the following test failures are new to me: $ /tmp/testdir/gltests/test-btoc32-1.sh /tmp/testdir/gltests/test-btoc32.c:49: assertion 'btoc32 (c) == c' failed CEE5207E The signal SIGABRT was received. $ /tmp/testdir/gltests/test-mbrtoc32-1.sh /tmp/testdir/gltests/test-mbrtoc32.c:108: assertion 'wc == c' failed CEE5207E The signal SIGABRT was received. $ /tmp/testdir/gltests/test-mbrtoc32-5.sh /tmp/testdir/gltests/test-mbrtoc32.c:115: assertion 'mbsinit (&state)' faid CEE5207E The signal SIGABRT was received. I tested using using Git 49c6f78c. Poking a bit into the test-btoc32-1.sh failure, I saw that it occurred when btoc32(4) yielded 156, which seems consistent with an IBM-1047-to-ASCII mapping. (Per Wikipedia, 0-3 is the same as ASCII, but 4 is a "SEL" character. And btoc32(5) returns 9.) > b) a feature request for the 'gperf' program, to generate two code > bodies, one for ASCII and one for EBCDIC. What about generating a translation table at compile/run time, that is used if ASCII is unavailable? Something like xlate['A'] = 65; xlate['B'] = 66; ... xlate['Z'] = 90; ... c = xlate[c]; As I recall, there are EBCDIC variants with minor differences in the positions of certain punctuation marks, and while they may or may not be commonly used on z/OS, it would be desirable to remain robust against that possibility. --Daniel -- Daniel Richard G. || skunk@iSKUNK.ORG My ASCII-art .sig got a bad case of Times New Roman.