Re: z/OS, iconv, and gperf

[Daniel Richard G.]

On Sun, 2020 Jan 19 16:59-05:00, Bruno Haible wrote:
> 
> The intended outcome is that a gperf-generated mapping function, say,
> for
>     FOO, "BAR"
> performs equivalently to
>     if (strcmp (arg, "FOO") == 0)
>       return "BAR";
> just faster. Can you find the suitable compiler settings and #pragmas
> - inside and outside the gperf-generated code - to make this happen?

But what good will that do, if the (ASCII-consuming) gperf code receives
e.g. the EBCDIC form of "ISO-8859-1"? "#pragma convert" only works at
compile time, not run time.

In order for a literal string in a user program to get passed in as
ASCII, the user program itself would also need to be compiled with this
#pragma surrounding the string. (I don't think that is a reasonable thing
to ask of user programs, and it doesn't address non-literal strings in
any event.)

There would need to be an additional step of explicit run-time EBCDIC-to-
ASCII conversion of the input in order for ASCII-based gperf code to
work on this platform. Is that feasible?

> In theory, it would be possible to introduce an option to gperf that
> makes it generate ASCII- and EBCDIC-based tables in the same output
> file, and let the compiler pick the right one at compile-time. But
> this is a *lot* of work. Therefore, if you can get the same result
> through compiler settings and #pragmas, that will be the way to go.

It's not the same result. Only the former would allow "char c = 0xC1" to
be recognized as a letter "A". The latter just makes 'A' == 0x41.


--Daniel


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