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