------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=791 --- Comment #5 from Philip Hazel <[email protected]> 2008-12-17 15:24:09 --- On Wed, 17 Dec 2008, Martin Jerabek wrote: > If it is acceptable to you I will > modify the sources in such a way that I replace all character constants > with macros which are defined as normal literals (e.g. '*') or as UTF-8 > literals (e.g. '\x2A') depending on --enable-utf8: Yes, that seems OK to me. > If --enable-ebcdic is also passed, a warning is issued saying that the > resulting PCRE library will *only* support UTF-8 and not EBCDIC. > Alternatively configure could return an error in this case to make > sure that the warning is not overlooked, and we could introduce a new > option like --enable-utf8-ebcdic to compile a UTF-8-only PCRE library > on EBCDIC platforms. In this case all appropriate functions would > return an error if PCRE_UTF8 is not passed to them. I do not mind which of those solutions you adopt. I think this is probably pretty rare, and those who use it will probably know what they are doing - so do whatever is easiest. > Do you really mean to replace *all* PCRE function names with macros > which would would then be defined, e.g., with and without _ebcdic > appended? What I meant was that you could have two sets of definitions like *define pcre_compile pcre_compile_ebcdic or *define pcre_compile pcre_compile_utf8 for the two different compilations, and somehow get these included in the compilation - perhaps by modifying config.h? > I think this is rather messy but necessary if someone wanted > to use both an EBCDIC-only and a UTF-8-only PCRE library in the same > process. Exactly! Regards, Philip -- Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email -- ## List details at http://lists.exim.org/mailman/listinfo/pcre-dev
