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