--- In [email protected], "entropyreduction" <alancampbelllists+ya...@...> wrote: > > if (m_iExecRet == PCRE_ERROR_NOMATCH) > { > ..... > if (m_bJumpNL && m_iOffset + 1 < m_iLenSubject && > m_pszSubject[m_iOffset] == '\r' && > m_pszSubject[m_iOffset+1] == '\n') > m_iOffset++; > }
I don't understand the above code. If exec returns NOMATCH, there is no need to do anything AFAIK. Certainly don't want to keep trying to match when there are no more matches. Might improve performance to remove that if it proves harmless. Or, maybe the meat of the logic is in the omitted "...." code? Looking back over old notes we did have an issue where if (during repeated executions for retrieval of multiple matches), you MATCH the empty string, the next execution needs to start at an offset of current position +1. The purpose of that is to avoid getting into an endless loop when the result is a MATCH and the length of the match is zero (i.e., == ""). If the character at the current offset (when it is the position of an empty match) is '\r' and the next character is '\n', and the multiline option is set, it was desirable that you would also skip over the '\n' (so in that case, move +2.). Regards, Sheri
