From: Bruno Haible <bruno@clisp.org>
To: "Daniel Richard G." <skunk@iskunk.org>
Cc: bug-gnulib@gnu.org
Subject: Re: z/OS, iconv, and gperf
Date: Sun, 19 Jan 2020 22:59:47 +0100 [thread overview]
Message-ID: <4635927.XszyHSjnn0@omega> (raw)
In-Reply-To: <a1cdf22c-c36f-4eee-b946-8e7926ccdb7a@www.fastmail.com>
Hi Daniel,
> > > 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.
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?
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.
Bruno
next prev parent reply other threads:[~2020-01-19 21:59 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-22 2:28 [PATCH] IBM z/OS + EBCDIC support Daniel Richard G.
2015-09-22 15:23 ` Eric Blake
2015-09-22 19:27 ` Daniel Richard G.
2015-09-22 20:00 ` Paul Eggert
2015-09-22 20:08 ` Eric Blake
2015-09-22 20:51 ` Daniel Richard G.
2015-09-22 19:32 ` Paul Eggert
2015-09-22 19:46 ` Paul Eggert
2015-09-22 20:37 ` Daniel Richard G.
2015-09-22 22:03 ` Paul Eggert
2015-09-22 23:44 ` Daniel Richard G.
2015-09-23 2:02 ` Paul Eggert
2015-09-23 6:58 ` Daniel Richard G.
2015-09-23 19:05 ` Paul Eggert
2015-09-23 19:29 ` Paul Eggert
2015-09-23 21:57 ` Daniel Richard G.
2015-09-25 7:29 ` Paul Eggert
2015-09-26 0:25 ` Daniel Richard G.
2015-09-26 2:49 ` Paul Eggert
2015-09-26 4:39 ` Daniel Richard G.
2015-09-26 16:08 ` Ben Pfaff
2015-09-27 6:31 ` Daniel Richard G.
2015-09-27 6:59 ` Paul Eggert
2015-09-28 2:09 ` Daniel Richard G.
2015-10-15 4:49 ` Daniel Richard G.
2016-08-18 0:47 ` Paul Eggert
2016-08-18 8:24 ` Daniel Richard G.
2016-08-18 8:53 ` Paul Eggert
2016-08-19 8:20 ` Daniel Richard G.
2016-08-19 11:03 ` Bruno Haible
2016-08-19 19:28 ` Paul Eggert
2016-08-19 20:38 ` Daniel Richard G.
2019-12-19 4:57 ` z/OS configure triple Bruno Haible
2019-12-20 0:22 ` Daniel Richard G.
2019-12-20 6:29 ` Bruno Haible
2019-12-19 5:16 ` z/OS, iconv, and charset aliases Bruno Haible
2019-12-19 5:21 ` Bruno Haible
2019-12-20 4:38 ` Daniel Richard G.
2019-12-20 8:19 ` Bruno Haible
2019-12-20 18:23 ` Daniel Richard G.
2019-12-21 5:49 ` z/OS, iconv, and gperf Bruno Haible
2020-01-09 5:48 ` Daniel Richard G.
2020-01-19 21:52 ` Bruno Haible
2020-01-19 21:59 ` Bruno Haible [this message]
2020-01-19 22:32 ` Daniel Richard G.
2020-01-20 0:13 ` Bruno Haible
2020-01-22 6:38 ` Daniel Richard G.
2015-09-22 19:50 ` [PATCH] IBM z/OS + EBCDIC support Paul Eggert
2015-09-22 20:47 ` Daniel Richard G.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4635927.XszyHSjnn0@omega \
--to=bruno@clisp.org \
--cc=bug-gnulib@gnu.org \
--cc=skunk@iskunk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).