--- In [email protected], "Sheri" <sheri...@...> wrote: ok, quick fixes,try em and see
regexPlugin210_100701.zip in the usual http://tech.groups.yahoo.com/group/power-pro/files/0_TEMP_/AlansPluginProvisional/ Added exec option "slow" == PCRE_NO_START_OPTIMIZE compile option "usp" == PCRE_UCP pseudo exec option "mark" "k", == PCRE_MINE_MARK There's a sample script regexMark.powerpro, simple case seems to work. > > pcre_dfa_exec dos say for extra data options: > > > > "the match_limit and match_limit_recursion fields are not used, For this > > matching function, the match_limit and match_limit_recursion fields are not > > used" > > > > Not sure if I made that sanity check. Will look Still haven't. > > and in same docs the mark field isn't shown in the struct or mentioned, so > > I imagine it too shouldn;t ever be allowed with dfa option? > > agree, because mark is only mentioned in connection with pcre_exec, not > pcre_dfa_exec Haven't fixed yet. > > > > Does mark make sense with pcrematchcount? Probably not. > I would think that the only places it makes no absolutely sense is where > pcre_exec will not get used (e.g., pcreCompile), so I guess I would not > exclude it from pcrematchcount. User should be cautioned not to apply the > option there (or anywhere) unless he/she plans to retrieve the mark if pcre > happens to set one (which it would only do if the user's pattern asks for one > and the conditions encountered support it). It was easiest to let it rip on all cases where pcre_exec used. > But, if it is a mess to implement, it is ok with me if you want to exclude it > from everything except pcreMatch and pcreReplaceCallback. Main thing is, do > not ever want the overhead unless the option has been set. Sure, done. Meanwhile, I've noticed I added a small overhead in every case pcre_exec is used: I always include a pointer to a pcre_extra block, even though in the default case it's empty. That probably means ever pcre_exec checked fora bunch of non-zero entries in the pcre_extra struct, comes up negative every time but still has to do the tests. Probably makes infinitesimal difference to exec time, but will fix. > > Is PCRE_UCP both exec and compile option, or just one, if so which? > > compile time only afaict Done, not tested. Okay, back to *MARK. pcretest doc: "If the variable that the mark field points to is non-NULL for a match, non-match, or partial match, pcretest prints the string to which it points. For a match, this is shown on a line by itself, tagged with "MK:". " Er, okay, not entirely sure I understand why *MARK can be meaningful for a non-match, but who am I to quibble? So, here;'s what happens after pcre_exec is called an a bunch of result-checking happens. aResult is an enum you can probably guess what each value means. Would it make sense to try to retrieve *MARK name when resultPostNoMatchAnchored comes back (if that doesn't mean anything to you: and after all this time it doesn't make much sense to me: lemme know and I'll go find out how I determine resultPostNoMatchAnchored) aResult = m_pPatternCompiledCurrent->exec(); if (bUseMark && (aResult == resultOK || aResult == resultPartialMatch || aResult == resultMatch || aResult == resultNoMatch)) strMark = m_pPatternCompiledCurrent->getMarkName(); switch (aResult) { case resultOK: case resultPartialMatch: case resultMatch: aResult = onMatch(piRetVal); break; case resultPostNoMatchAnchored: break; case resultNoMatch: //not found if (m_nPatternsMatched > 0) //not found at end of repeated match return resultMatch; else { *piRetVal = m_usNdxBase - m_usNdxBase; return resultNoMatch; }
