Here's a PCRE build which treats CRLF as newline by default: http://homepage.hispeed-sr.ch/julp/pcre_CRLF.zip You need to rename it to whatever your plugin is linked to in order to use it.
I put the options I used in the output of pcre_version() to make it easier to work with two versions of the library. While I was tweaking the source, I put pcre_version() into the POSIX library so that we can use it again (it's smaller because it doesn't contain the stuff we aren't using such as callouts). Would someone please confirm that UTF-8 processing still works with that? I don't forsee any other problems since we've been using the POSIX library for years but in case it breaks something else, let me know as well. > CRLF. But it can be changed by the caller (the plugin), so if not > compiled with CRLF, the call needs a way to specify CRLF. I guess the > call needs a way to specify whichever lineending the user is dealing > with (e.g., we sometimes read unix text on a windows platform). Unfortunately this only works when using the pcre-specific interface as opposed to the generic regex interface the plugin is using. So the only way to specify such options as things stand is when building the library. This means that users will have to keep two versions of the library around if they want to process standard as well as CRLF text and either: -unload the plugin and rename the library afterwards to switch between one type of newline to the other -use two plugins (one of them renamed and linked to a renamed library) I know... it's a kludge. If anyone has a better idea (short of dumping the regex plugin in favor of a new pcre plugin), let me know.
