bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: z/OS, iconv, and gperf


From: Daniel Richard G.
Subject: Re: z/OS, iconv, and gperf
Date: Wed, 22 Jan 2020 01:38:41 -0500
User-agent: Cyrus-JMAP/3.1.7-754-g09d1619-fmstable-20200113v1

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. || address@hidden
My ASCII-art .sig got a bad case of Times New Roman.

Attachment: zos-iconv-fix.patch.txt
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]