Re: z/OS, iconv, and gperf

[Daniel Richard G.]

On Sat, 2019 Dec 21 00:49-05:00, Bruno Haible wrote:
> 
> Oh, certainly many of the IBM-nnn encodings are variants of what
> Microsoft and the rest of the world do regarding codepage nnn. Find an
> extensive comparison at
> https://haible.de/bruno/charsets/conversion-tables/index.html .
>
> You find the tools to extract the conversion tables and compare
> them here:
> https://haible.de/bruno/charsets/conversion-tables/tools.html

I downloaded the tools, and gave them a try. I will discuss sending you
the resulting information in a private message, as it is fairly large.

> > There isn't a way to compile gperf tables in an encoding-agnostic
> > manner?
>
> No. gperf works by using character values as indices into arrays; the
> arrays are filled by gperf at code generation time.
>
> Can you experiment with the pragmas to resolve this? For this, you
> best take the gperf source distribution, remove the part that emits
> the error message in gperf/src/output.cc:2103, and then work with
> "make check" to get things working.

What is the intended outcome, however? There are pragmas to change the
encoding assumed by the compiler in character/string literals, but if
that is set to ASCII, then the compiled code will also assume ASCII
input, which would typically not be the case on this system.

I suppose in theory, gperf could be given an option to generate
code that expects EBCDIC instead of ASCII, and that source could be
used on this system. However, gperf has no such encoding-related
option, probably because anything other than ASCII is too niche for
their purposes.


--Daniel


-- 
Daniel Richard G. || address@hidden
My ASCII-art .sig got a bad case of Times New Roman.