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
