Sheri wrote: > I'm struggling to understand what you're saying. There were two empty > lines in the input string. Surely the last "Hello" in the replacement > is there because it matched the last one?
I'm talking about the implicit empty line after the last CRLF, at the very end of the string: one could argue ...\r\nHello is the expected result. > I think the problem producing the \rHelloHello\n (of which only the > \r\n should be in the output) is another anomoly of sending shortened > strings instead of offsets to PCRE. I don't think so because: -your theory doesn't explain why the other occurences of CRLF are processed as expected -the "any" build of PCRE is apparently interpreting \r alone as a newline in this case which is why you get a match in the middle of the CRLF sequence (I can't fix that but you can by using the CRLF build) -the plugin logic would normally produce two empty matches in a row in this circumstance (this I can fix so that you would get a single match... can someone determine that this is how other regex implementations handle zero-character matches?) > There is the option PCRE_NOTBOL > which is available to the posix interface which I think should be set > after the first match in a global operation. Could you verify if that > is not currently happening in the plugin and could we possibly try one > where it is? That is a fair request (except that PCRE_NOTBOL is not available to the PCRE interface... REG_NOTBOL is). The trouble is that this would fix a specific problem with the global services but would not fix the general problem (lookbehinds and such are not reliable). I don't like such fixes because they introduce inconsistencies. Now, if there was a case where this BOL business proved to be an impediment in real-word usage of the regex plugin (as opposed to the corner cases we use for testing), I could put the partial fix in. Again, in this case, this is NOT the problem... in fact, blindly setting REG_NOTBOL would probaly yield yet another unexpected result: "CRLFCRLFCRLF" would yield "matchCRLFCRLFmatchCRLF" for example. To deal with that issue, I would presumably have to detect whether a line actually begins at the current position or not by looking at the characters preceding the current position in the input string... not a big deal except for the fact that the plugin is not aware of what the library uses as newlines! I could of course do what I did with 1.5.2 and assume that the CRLF build is being used. On top of that, I wouldn't even know how I should deal with cases where newlines immediately preceding the current position have been consumed and whether the rule should be different if they have been arbitrarily consumed to avoid infinite loops. Obviously, I would rather keep the rules simple and consistent. Switching from the POSIX to the PCRE interface would be a solution but I'm still not volunteering for that at the moment although I'm sure you're right in insisting that it would be fairly easy.
